From owner-ipng@sunroof.eng.sun.com Sun Sep 1 17:38:41 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g820cfwf019267; Sun, 1 Sep 2002 17:38:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g820ceRd019266; Sun, 1 Sep 2002 17:38:40 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g820cZwf019259 for ; Sun, 1 Sep 2002 17:38:35 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g820clPG014811 for ; Sun, 1 Sep 2002 17:38:47 -0700 (PDT) Received: from ALPHA2.ITS.MONASH.EDU.AU (alpha2.its.monash.edu.au [130.194.1.4]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA00818 for ; Sun, 1 Sep 2002 18:38:41 -0600 (MDT) Received: from kapow.its.monash.edu.au ([130.194.1.71]) by vaxc.cc.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01KM0TBD8Q969I5BVD@vaxc.cc.monash.edu.au> for ipng@sunroof.eng.sun.com; Mon, 02 Sep 2002 10:38:29 +1000 Received: from kapow (unknown [127.0.0.1]) by localhost (Postfix) with ESMTP id 6363120DA8; Mon, 02 Sep 2002 10:18:15 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by kapow.its.monash.edu.au (Postfix) with ESMTP id 8E9E22000E; Mon, 02 Sep 2002 10:08:28 +1000 (EST) Date: Mon, 02 Sep 2002 10:08:28 +1000 From: Greg Daley Subject: Re: I-D ACTION:draft-daley-ipv6-mcast-dad-00.txt To: Richard Draves Cc: richard.nelson@eng.monash.edu.au, ipng@sunroof.eng.sun.com Reply-to: greg.daley@eng.monash.edu.au Message-id: <3D72ABFC.1070108@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 References: <7695E2F6903F7A41961F8CF888D87EA8063CEE78@red-msg-06.redmond.corp.microsoft.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Richard, There are some design ideas which we haven't necessarily explained. We'll try to elaborate on the ideas. Maybe you can recommend some different approaches. Richard Draves wrote: > The way MLD works today, if you don't have a valid link-local address to > use as the IP Source, you use the unspecified address instead. It sounds > like (section 4.1) you want to change this? I assume so the router can > unicast a response. I think this is a problem because until DAD > completes for the link-local address it's really not right to accept > packets sent to it. So your optimization can not apply to the link-local > address, only subsequent addresses. RFC 2710 (MLD) doesn't have any mention of unspecified addresses, (MLDv2 draft does). In the RFC, MLD requires reports which come from unspecified source address (actually a non link-local) to be dropped (page 12). This is seemingly at odds with the state diagrams, which indicates that nodes send their report when starting to listen to an address (which as you say is difficult for the solicited address for the link-local). Similarly, in MLDv2 draft, unspecified source address may be used, but reports with this address MUST be ignored by routers (S 4.2.13) Our main goal is to allow the existing MLD nodes to recognise the report, rather than to get a unicast response. In fact our draft specifies that there will not be a unicast response. I will clean up the language in the second paragraph of sec 4.1 as follows: s/address will not have a unicast response/ report will not have a unicast response/ Since there will be no unicast packets going to this address, and the source address is only to ensure that the packet does not arrive from off-link, I think that it may be alright to send a packet from this address. I'm happy to listen to suggestions though. > > You say only the first MLD Report may be a report-requesting-response. > Don't you mean the first one for each solicited-node multicast address? > Or even more accurately (since some implementations allow an interface > to be "reset" to that DAD etc is redone), just strike this sentence and > leave the requirement as only unsolicited reports may request a > response? What is your intent for retransmitted reports - are they not > supposed to request a response? Yes, the statement should be "for each solicited-node multicast address". retransmission was expected to be normal MLD (responses to Queries, and periodic sending of unsolicited reports-every 10s?). In these cases we thought that it was neater to ensure that the periodic reports didn't request response, since the incidence of periodic reports could easily exceed the number of DAD's occurring on a busy link. This would mean a small additional overhead in looking up each multicast group, and discovering its existence (therefore not sending a response). Maybe it is better to say that "response MUST NOT be requested, unless DAD is being performed for an address related to the solicited-node multicast address" Is that reasonable ? Greg -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 2 00:50:05 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g827o5wf019719; Mon, 2 Sep 2002 00:50:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g827o5VL019718; Mon, 2 Sep 2002 00:50:05 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g827o0wf019711 for ; Mon, 2 Sep 2002 00:50:00 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g827oCPG013620 for ; Mon, 2 Sep 2002 00:50:13 -0700 (PDT) Received: from md.swissinfo.org ([146.159.4.100]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA13025 for ; Mon, 2 Sep 2002 01:50:06 -0600 (MDT) From: neilson@swissinfo.org Received: from fugu.sri.ch ([194.6.181.33]) by md.swissinfo.org ([146.159.6.10]) with SMTP (MDaemon.PRO.v6.0.4.R) for ; Mon, 02 Sep 2002 09:50:02 +0200 Received: from [210.186.240.11] by fugu.sri.ch with HTTP; Mon, 2 Sep 2002 09:49:59 +0200 Date: Mon, 2 Sep 2002 07:49:59 +0000 Message-ID: <3D728DEE000000AE@fugu.sri.ch> Subject: RE: IPV6 Interview Question and critics To: ipng@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" X-MDRemoteIP: 194.6.181.33 X-Return-Path: neilson@swissinfo.org X-MDaemon-Deliver-To: ipng@sunroof.eng.sun.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g827o0wf019712 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Sun, 1 Sept 2002, M.Mognesvari wrote :- Refering to section 2.4 , I agree with your proposal of using the psedu-random sequence of interface identifiers via an MD5 hash. RFC1948 suggest the use of source IP address,............... to generate the function for each unique connection using MD5 hash will pose a greater overhead for the sender( server ). As proposed in the RFC it is better to used the temporary addresses ( after expired ; could be traced with timeout variable ) rather than creating a new one for each and every connection.The focus is to minimise the overhead generated through interface identifiers creation. Neilson ________________________________________ Dreaming of a Swiss Account? Get it here: http://freemail.swissinfo.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 Mon Sep 2 23:35:47 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g836Zkwf022644; Mon, 2 Sep 2002 23:35:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g836Zkbn022643; Mon, 2 Sep 2002 23:35:46 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g836Zfwf022636 for ; Mon, 2 Sep 2002 23:35:41 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g836ZtPG015707 for ; Mon, 2 Sep 2002 23:35:55 -0700 (PDT) Received: from dot-god.com (d150-250-196.home.cgocable.net [24.150.250.196]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA05668 for ; Mon, 2 Sep 2002 23:35:49 -0700 (PDT) Received: from localhost (baptista@localhost) by dot-god.com (8.11.4/8.11.4) with ESMTP id g836c6n19080 for ; Tue, 3 Sep 2002 02:38:06 -0400 Date: Tue, 3 Sep 2002 02:38:06 -0400 (EDT) From: Joe Baptista To: Subject: I want a pretty IPv6 address to put on my fireplace this xmas Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi: Some time ago I asked a number of questions concerning IPv6 for an interview. I want to thank all who participated and helped. I will be publishing the article here when it's up. But I want to go one step further. I want to test IPv6 out for myself. And so far I have not had much luck finding an allocation. I've visited the 6bone and contacted some 6bone people about getting an allocation to test for a future article. they recommended i try 6to4 but i still need a connection to the 6bone. in any case i would rather connect directly to the 6bone. am i deluding myself in thinking this can be accomplished? my local isp - a major canadian company has no idea what ipv6 is. if someone here can provide me with a test address and a place to connect that would be nice. Cheers Joe Baptista -- Planet Communications & Computing Facility a division of The dot.GOD Registry, Limited -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 3 04:35:30 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g83BZUwf023589; Tue, 3 Sep 2002 04:35:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g83BZUjn023588; Tue, 3 Sep 2002 04:35:30 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g83BZNwf023581 for ; Tue, 3 Sep 2002 04:35:23 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g83BZcuH004290 for ; Tue, 3 Sep 2002 04:35:38 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA08284 for ; Tue, 3 Sep 2002 04:35:32 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21950; Tue, 3 Sep 2002 07:33:57 -0400 (EDT) Message-Id: <200209031133.HAA21950@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-ipv6-ipaddressassign-03.txt Date: Tue, 03 Sep 2002 07:33:56 -0400 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 IP Version 6 Working Group Working Group of the IETF. Title : A flexible method for managing the assignment of bites of an IPv6 address block Author(s) : M. Blanchet Filename : draft-ietf-ipv6-ipaddressassign-03.txt Pages : 9 Date : 2002-8-30 This document proposes a method to manage the assignment of bits of an IPv6 address block or range. When an organisation needs to make an address plan for its subnets or when an ISP needs to make an address plan for its customers, this method enables the organisation to postpone the final decision on the number of bits to partition in the address space they have. It does it by keeping the bits around the borders of the partition to be free as long as possible. This scheme is applicable to any bits addressing scheme using bits with partitions in the space, but its first intended use is for IPv6. It is a generalization of RFC1219 and can be used for IPv6 assignments. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-ipaddressassign-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-ipv6-ipaddressassign-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-ipv6-ipaddressassign-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: <2002-8-30145202.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-ipaddressassign-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-ipaddressassign-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-8-30145202.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 Tue Sep 3 07:55:45 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g83Etiwf023924; Tue, 3 Sep 2002 07:55:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g83EtieH023923; Tue, 3 Sep 2002 07:55:44 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g83EtVwf023908; Tue, 3 Sep 2002 07:55:32 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g83EtluH024495; Tue, 3 Sep 2002 07:55:47 -0700 (PDT) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA02191; Tue, 3 Sep 2002 08:55:37 -0600 (MDT) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id RAA16681; Tue, 3 Sep 2002 17:55:24 +0300 Date: Tue, 3 Sep 2002 17:55:24 +0300 Message-Id: <200209031455.RAA16681@burp.tkv.asdf.org> From: Markku Savela To: Francis.Dupont@enst-bretagne.fr CC: itojun@iijlab.net, mrw@windriver.com, Erik.Nordmark@Sun.COM, kre@munnari.OZ.AU, dthaler@windows.microsoft.com, charliep@iprg.nokia.com, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com In-reply-to: <200208311507.g7VF7X6o044997@givry.rennes.enst-bretagne.fr> (message from Francis Dupont on Sat, 31 Aug 2002 17:07:33 +0200) Subject: Re: [mobile-ip] RE: RFC 2462 DAD optimization References: <200208311507.g7VF7X6o044997@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 > > In your previous mail you wrote: > > > >I'm going to ingore RFC 2710 on this point. I do not send MLD for link > > >local multicast groups. > > > > then your device will have trouble operating on coming switches > > that support MLD snooping, and it will be very difficult to > > track the issue down (extraordinary support load to your colleagues). > > i suggest you to follow RFC2710. > > => I strongly support Itojun! Please don't ignore standards just because > NIBY. It's not yet a standard, right? It's still RFC, and I'm just giving my comments on it. I'm only trying to work as a "fire fighter" to prevent dubious requirements to get into standards (and hurting everyone there). NIBY??? (if this is supposed to mean "Not Invented By You", I'm somewhat offended). My complaint about sending MLD reports on link local groups has nothing to do with anything I invented or didn't invent. It purely technical issue, based on - there is no reason for using MLD for link local multicast groups as far IPv6 (layer-3) is concerned. - the only presented reason for them is some layer-2 snooping. This is layer violation, a hack, which should not be codified in standards. - at least it should be optional for link local multicast groups used in Neighbor discovery - illogical definition: you cannot join solicited nodes multicast group before you have address, you cannot do DAD without listening to solicited nodes multicast group - layer-2 snooper can get the same information from the ND traffic directly, - sending MLD's on big monolithic stacks, can be minor issue (code is already there), but for small devices, like cell phones, modularity is desired. One should be able to run IPv6 without MLD. - if layer-2 snoop is going to make use of MLD, it or some part of it must actually be node on the network and work as a multicast router to make queries (a switch can be powered off when host is attached or just powered off and loses the state) - in practice, there will never be "leave group" MLD's from hosts on the link (hosts leave the link usually by user just unplugging it). -- ps. There has been some discussion about having DAD optional on 3GPP links. Requiring MLD would add more packets to that link: MLD join + DAD. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 3 08:11:46 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g83FBjwf024029; Tue, 3 Sep 2002 08:11:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g83FBj4t024028; Tue, 3 Sep 2002 08:11:45 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g83FBewf024021 for ; Tue, 3 Sep 2002 08:11:40 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g83FBtPG000561 for ; Tue, 3 Sep 2002 08:11:55 -0700 (PDT) Received: from alcove.wittsend.com (alcove.wittsend.com [130.205.0.10]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA26504 for ; Tue, 3 Sep 2002 08:11:49 -0700 (PDT) Received: (from mhw@localhost) by alcove.wittsend.com (8.11.6/8.11.6) id g83F9Ss22656; Tue, 3 Sep 2002 11:09:28 -0400 Date: Tue, 3 Sep 2002 11:09:28 -0400 From: "Michael H. Warfield" To: Joe Baptista Cc: ipng@sunroof.eng.sun.com Subject: Re: I want a pretty IPv6 address to put on my fireplace this xmas Message-ID: <20020903150928.GA18266@alcove.wittsend.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, Sep 03, 2002 at 02:38:06AM -0400, Joe Baptista wrote: > Hi: > Some time ago I asked a number of questions concerning IPv6 for an > interview. I want to thank all who participated and helped. I will be > publishing the article here when it's up. > But I want to go one step further. I want to test IPv6 out for myself. > And so far I have not had much luck finding an allocation. I've visited > the 6bone and contacted some 6bone people about getting an allocation to > test for a future article. they recommended i try 6to4 but i still need a > connection to the 6bone. in any case i would rather connect directly to > the 6bone. am i deluding myself in thinking this can be accomplished? And what is the problem with FreeNet6 ? I've set up a couple of accounts and have a /48 allocation from them for my primary network and a couple of /64 P-P allocations for some road-warrior testing. It takes a couple of minutes to add an account for an E-Mail address and then you just configure and run the tsp package to get your allocation and fire up the tunnel. I've been using this under Linux for over 6 months to connect to the 6Bone. There are even options to add reverse lookup name servers. Unfortunately, the 6Bone reverse name lookups use ip6.int and the production reverse lookups use ip6.arpa. AFAIK, no delegation has been installed for the ip6.arpa reverse lookups for the 6Bone, so they are not going to work reliably, anyways. I've only run into one real gotcha and it has nothing to do with FreeNet6, directly. Under Linux, if you are doing IPv6 routing (IPv6 forwarding enabled), the Linux kernel ignores the ::/0 default routes. I had to modify the tsp template scripts to add a ::/1 route for my default route back to freenet6 and for my routes from my subnet routers back to my primary router. Seems that this was done intentionally to disallow people from accidentally routing site locals outside of the site. That only affects you if you are using Linux as a router and you are getting a /48 prefix. The FreeNet6 /64 allocations are P-P only for a single host and not used to route a network so IPv6 forwarding on the Linux host would not be enabled for that and the default ::/0 route would then work. > my local isp - a major canadian company has no idea what ipv6 is. FreeNet6 is up in Canada, no less... :-) > if someone here can provide me with a test address and a place to connect > that would be nice. Try them. Trivial. > Cheers > Joe Baptista > -- > Planet Communications & Computing Facility > a division of The dot.GOD Registry, Limited Mike -- Michael H. Warfield | (770) 985-6132 | mhw@WittsEnd.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of 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 Sep 3 09:54:59 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g83Gswwf024391; Tue, 3 Sep 2002 09:54:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g83Gsw1B024390; Tue, 3 Sep 2002 09:54:58 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g83Gsiwf024372; Tue, 3 Sep 2002 09:54:44 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g83GswPG011952; Tue, 3 Sep 2002 09:54:58 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA01230; Tue, 3 Sep 2002 09:54:52 -0700 (PDT) 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 g83Gslh29785; Tue, 3 Sep 2002 18:54:48 +0200 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 SAA19790; Tue, 3 Sep 2002 18:54:48 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id g83Gsj6o054279; Tue, 3 Sep 2002 18:54:45 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200209031654.g83Gsj6o054279@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Markku Savela cc: itojun@iijlab.net, mrw@windriver.com, Erik.Nordmark@Sun.COM, kre@munnari.OZ.AU, dthaler@windows.microsoft.com, charliep@iprg.nokia.com, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] RE: RFC 2462 DAD optimization In-reply-to: Your message of Tue, 03 Sep 2002 17:55:24 +0300. <200209031455.RAA16681@burp.tkv.asdf.org> Date: Tue, 03 Sep 2002 18:54:45 +0200 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's not yet a standard, right? => it is a proposed standard. It's still RFC, => ???? and I'm just giving my comments on it. I'm only trying to work as a "fire fighter" to prevent dubious requirements to get into standards (and hurting everyone there). => there is a time for this : last call(s) for the next version which is proposed for the IGMPv3/MLDv2 upgrade and draft standard status. - there is no reason for using MLD for link local multicast groups as far IPv6 (layer-3) is concerned. => there is a very well known reason: snooping by layer-2 switches. - the only presented reason for them is some layer-2 snooping. This is layer violation, a hack, which should not be codified in standards. => so you should flame the draft-ietf-magma-snoop-02.txt document in the magma list. - at least it should be optional for link local multicast groups used in Neighbor discovery => I can't see how it can be optional: either it is useful so is recommended/required, or it is not useful so is not recommended/required. - illogical definition: you cannot join solicited nodes multicast group before you have address, => I don't understand: I can send a join message. you cannot do DAD without listening to solicited nodes multicast group => I agree. - layer-2 snooper can get the same information from the ND traffic directly, => no, layer-2 snooper can get the information (has someone joined this group) only through MLD snooping for any group, i.e., ND is not a special case. - sending MLD's on big monolithic stacks, can be minor issue (code is already there), but for small devices, like cell phones, modularity is desired. One should be able to run IPv6 without MLD. => this was already discussed and the consensus is that MLD is mandatory to implement. - if layer-2 snoop is going to make use of MLD, it or some part of it must actually be node on the network => no, the layer-2 snooper is a layer-2 snooper by definition. and work as a multicast router to make queries (a switch can be powered off when host is attached or just powered off and loses the state) => the MLD state is a soft state so this is not a real problem. - in practice, there will never be "leave group" MLD's from hosts on the link (hosts leave the link usually by user just unplugging it). => same. ps. There has been some discussion about having DAD optional on 3GPP links. Requiring MLD would add more packets to that link: MLD join + DAD. => s/would add/adds/ because MLD is mandatory. But you still can remove the support of multicast on the links (and remove MLD too). Perhaps this is the best solution if your argument is that multicast just sucks. 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 Sep 3 10:27:36 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g83HRZwf024614; Tue, 3 Sep 2002 10:27:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g83HRYYi024613; Tue, 3 Sep 2002 10:27:34 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g83HRMwf024598; Tue, 3 Sep 2002 10:27:22 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g83HRbuH026048; Tue, 3 Sep 2002 10:27:37 -0700 (PDT) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA21045; Tue, 3 Sep 2002 10:27:30 -0700 (PDT) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id UAA16876; Tue, 3 Sep 2002 20:27:22 +0300 Date: Tue, 3 Sep 2002 20:27:22 +0300 Message-Id: <200209031727.UAA16876@burp.tkv.asdf.org> From: Markku Savela To: Francis.Dupont@enst-bretagne.fr CC: itojun@iijlab.net, mrw@windriver.com, Erik.Nordmark@Sun.COM, kre@munnari.OZ.AU, dthaler@windows.microsoft.com, charliep@iprg.nokia.com, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com In-reply-to: <200209031654.g83Gsj6o054279@givry.rennes.enst-bretagne.fr> (message from Francis Dupont on Tue, 03 Sep 2002 18:54:45 +0200) Subject: Re: [mobile-ip] RE: RFC 2462 DAD optimization References: <200209031654.g83Gsj6o054279@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 > - there is no reason for using MLD for link local multicast groups > as far IPv6 (layer-3) is concerned. > > => there is a very well known reason: snooping by layer-2 switches. ...and which totally bogus, as such switch cannot utilize the information in any significant way. Remember, I'm talking about LINK LOCAL MULTICAST groups used in IPv6 NEIGHTBOR DISCOVERY. And, as linklocal all-nodes is ALREADY excempted from the MLD, what is left is *ONLY* the solicited node multicast. I vote that, it too is exempted. When is this joined? ONLY when node configures a NEW id for address, so what we are seeing on link, is two back-to-back messages: 1) join solicited node group (MLD), followed by 2) ND DAD probe I just can't see any significant use for the (1), even for layer-2 snooper. The probe alone carries exactly the same information as the useless MLD join. And whats worse, the switch will increase the probability of DAD "failing to do its suff"... (if it decides not to forward the DAD to all links based on some stale soft state -- it definetly cannot start querying at this point). Additionally, when ND is protected by IPSEC, the switch needs to do the IPSEC also. > - at least it should be optional for link local multicast groups used > in Neighbor discovery > > => I can't see how it can be optional: either it is useful so is > recommended/required, or it is not useful so is not > recommended/required. Right, I'm requesting it to be at least optional. I don't think it (MLD for link local ND groups) is useful for anything. > - illogical definition: you cannot join solicited nodes multicast > group before you have address, > > => I don't understand: I can send a join message. Yes, with "::" source address. Kinky.. :) > - if layer-2 snoop is going to make use of MLD, it or some part of it > must actually be node on the network > > => no, the layer-2 snooper is a layer-2 snooper by definition. Then it cannot send queries, and it's knowledge about solicited node groups is totally "soft", practically useless (unless it snoops other ND traffic, in which case it doesn't need MLD at all for those). > => s/would add/adds/ because MLD is mandatory. But you still can remove > the support of multicast on the links (and remove MLD too). Perhaps > this is the best solution if your argument is that multicast just sucks. Where did I say "multicast sucks". I definitely like multicast, I'm just talking about these link local groups here, and specifically about ND discovery part of 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 Sep 3 10:49:34 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g83HnYwf024761; Tue, 3 Sep 2002 10:49:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g83HnYOq024760; Tue, 3 Sep 2002 10:49:34 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g83HnSwf024753 for ; Tue, 3 Sep 2002 10:49:28 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g83HnhuH006700 for ; Tue, 3 Sep 2002 10:49:43 -0700 (PDT) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA03825 for ; Tue, 3 Sep 2002 10:49:38 -0700 (PDT) Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.194.24]) by e35.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id g83HnaBA078214; Tue, 3 Sep 2002 13:49:36 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.9.21]) by westrelay03.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g83HnWrB199692; Tue, 3 Sep 2002 11:49:36 -0600 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id g83Hk7A01046; Tue, 3 Sep 2002 13:46:07 -0400 Message-Id: <200209031746.g83Hk7A01046@rotala.raleigh.ibm.com> To: Jack.McCann@hp.com cc: ipng@sunroof.eng.sun.com Subject: IESG feedback on draft-ietf-ipngwg-rfc2553bis-06.txt Date: Tue, 03 Sep 2002 13:46:07 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IESG recently reviewed this document. No major issues, I think. However the following issues were raised and warrant investigation. Once these comments are addressed, I expect the IESG to approve the document. Comments: I only have draft 7 of 1003.1-2001 with me, so maybe some of these issues are bugs in draft 7. note: the above was then followed up with the following: I looked at my CD-ROM copy of The Open Group's SUSv3 (their version of the Austin standard, also 1003.1-2001) and didn't find any differences from draft 7 on these issues.] In the middle of section 3.3, this sentence doesn't make any sense to me: The sin6_flowinfo field SHOULD be set to zero by an implementation prior to using the sockaddr_in6 structure by an application on receive operations. There's no reference to this in 1003.1-2001, as far as I can tell, and I don't even really understand what it means - does it mean that the previously "result only" sockaddr arg to accept() or recvfrom() is now "value-result", and that a non-zero sin6_flowinfo passed in as the value has some undesirable semantic? Does it mean that an application should always say "sin6->sin6_flowinfo = 0" after receiving it from an accept() or recvfrom()? In section 3.10, the text was updated to remove the extra prefixed underscore in the sockaddr_storage definition, but the struct was not. e.g. the struct has elements like "__ss_pad1" and the text refers to "_ss_pad1". This is true of all of the struct elements and the references to them in the comment. There's a similar problem with the definition for systems with an sa_len field, but there's also a second problem here: the definition of _SS_PAD2SIZE is incorrect. It needs to add back the sizeof(uint8_t) as well. (I actually checked this by compiling test programs). It would seem much simpler to just define _SS_PAD2SIZE as _SS_MAXSIZE - 2*_SS_ALIGNSIZE, but that would break parallelism with 1003.1-2001 so it's probably best to just add in the sizeof(uint8_t), i.e. #define _SS_PAD2SIZE (_SS_MAXSIZE - (sizeof (uint8_t) + sizeof (sa_family_t) + _SS_PAD1SIZE + _SS_ALIGNSIZE)) (This bug isn't in 1003.1-2001 since it doesn't mention sa_len at all) The last paragraph in section 4.4 seems odd; e.g. there's no parallel wording for or any of the other headers that gain new prototypes and structs and constants. Is it necessary? Section 6.1 doesn't describe EAI_OVERFLOW as a possible return value from getaddrinfo(), while 1003.1-2001 does. Conversely, 6.2 describes EAI_OVERFLOW as a possible return value from getnameinfo(), while 1003.1-2001 doesn't. The first paragraph of the Acks section reads oddly, switching from Richard to Rich and back again. Maybe just replace "Rich's" with "His" to avoid 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 Sep 3 16:56:27 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g83NuRwf025556; Tue, 3 Sep 2002 16:56:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g83NuR3x025555; Tue, 3 Sep 2002 16:56:27 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g83NuKwf025548 for ; Tue, 3 Sep 2002 16:56:20 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g83NuYPG007953 for ; Tue, 3 Sep 2002 16:56:35 -0700 (PDT) Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA10156 for ; Tue, 3 Sep 2002 17:56:29 -0600 (MDT) Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id g83NuSD02914; Tue, 3 Sep 2002 16:56:28 -0700 (PDT) Message-Id: <200209032356.g83NuSD02914@gamma.isi.edu> To: IETF-Announce: ; Subject: RFC 3306 on Unicast-Prefix-based IPv6 Multicast Cc: rfc-editor@rfc-editor.org, ipng@sunroof.eng.sun.com From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Tue, 03 Sep 2002 16:56:27 -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3306 Title: Unicast-Prefix-based IPv6 Multicast Addresses Author(s): B. Haberman, D. Thaler Status: Standards Track Date: August 2002 Mailbox: bkhabs@nc.rr.com, dthaler@microsoft.com Pages: 7 Characters: 12713 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ipngwg-uni-based-mcast-03.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3306.txt This specification defines an extension to the multicast addressing architecture of the IP Version 6 protocol. The extension presented in this document allows for unicast-prefix-based allocation of multicast addresses. By delegating multicast addresses at the same time as unicast prefixes, network operators will be able to identify their multicast addresses without needing to run an inter-domain allocation protocol. This document is a product of the IPNG Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <020903165435.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3306 --OtherAccess Content-Type: Message/External-body; name="rfc3306.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <020903165435.RFC@RFC-EDITOR.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 Tue Sep 3 16:58:30 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g83NwUwf025598; Tue, 3 Sep 2002 16:58:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g83NwTNx025597; Tue, 3 Sep 2002 16:58:29 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g83NwMwf025590 for ; Tue, 3 Sep 2002 16:58:22 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g83NwbuH013845 for ; Tue, 3 Sep 2002 16:58:37 -0700 (PDT) Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA07722 for ; Tue, 3 Sep 2002 16:58:31 -0700 (PDT) Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id g83NwUD03351; Tue, 3 Sep 2002 16:58:30 -0700 (PDT) Message-Id: <200209032358.g83NwUD03351@gamma.isi.edu> To: IETF-Announce: ; Subject: RFC 3307 on IPv6 Multicast Addresses Guidelines Cc: rfc-editor@rfc-editor.org, ipng@sunroof.eng.sun.com From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Tue, 03 Sep 2002 16:58:30 -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3307 Title: Allocation Guidelines for IPv6 Multicast Addresses Author(s): B. Haberman Status: Standards Track Date: August 2002 Mailbox: bkhabs@nc.rr.com Pages: 8 Characters: 15742 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-malloc-ipv6-guide-04.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3307.txt This document specifies guidelines that must be implemented by any entity responsible for allocating IPv6 multicast addresses. This includes, but is not limited to, any documents or entities wishing to assign permanent IPv6 multicast addresses, allocate dynamic IPv6 multicast addresses, and define permanent IPv6 multicast group identifiers. The purpose of these guidelines is to reduce the probability of IPv6 multicast address collision, not only at the IPv6 layer, but also at the link-layer of media that encode portions of the IP layer address into the MAC layer address. This document is a product of the Multicast-Address Allocation Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <020903165634.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3307 --OtherAccess Content-Type: Message/External-body; name="rfc3307.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <020903165634.RFC@RFC-EDITOR.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 Tue Sep 3 17:44:54 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g840iswf026516; Tue, 3 Sep 2002 17:44:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g840ir6X026515; Tue, 3 Sep 2002 17:44:53 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g840imwf026508; Tue, 3 Sep 2002 17:44:48 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g840j2PG029277; Tue, 3 Sep 2002 17:45:02 -0700 (PDT) Received: from ALPHA9.CC.MONASH.EDU.AU (alpha9.cc.monash.edu.au [130.194.1.9]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA22120; Tue, 3 Sep 2002 18:44:56 -0600 (MDT) Received: from kapow.its.monash.edu.au ([130.194.1.71]) by vaxh.cc.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01KM3M4PIGCW90QSWH@vaxh.cc.monash.edu.au>; Wed, 4 Sep 2002 10:44:38 +1000 Received: from kapow (unknown [127.0.0.1]) by localhost (Postfix) with ESMTP id 01FC32000B; Wed, 04 Sep 2002 10:44:38 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by kapow.its.monash.edu.au (Postfix) with ESMTP id 74F2F20008; Wed, 04 Sep 2002 10:44:31 +1000 (EST) Date: Wed, 04 Sep 2002 10:44:31 +1000 From: Greg Daley Subject: Re: [mobile-ip] RE: RFC 2462 DAD optimization To: Markku Savela Cc: greg.daley@eng.monash.edu.au, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Reply-to: greg.daley@eng.monash.edu.au Message-id: <3D75576F.1060606@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en, en-us References: <200209031654.g83Gsj6o054279@givry.rennes.enst-bretagne.fr> <200209031727.UAA16876@burp.tkv.asdf.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Markku, I'm not sure if this is just fuel for the fire, or another idea you haven't seen. Markku Savela wrote: >>From: Francis Dupont > > >> - there is no reason for using MLD for link local multicast groups >> as far IPv6 (layer-3) is concerned. >> >>=> there is a very well known reason: snooping by layer-2 switches. > > > ...and which totally bogus, as such switch cannot utilize the > information in any significant way. Remember, I'm talking about LINK > LOCAL MULTICAST groups used in IPv6 NEIGHTBOR DISCOVERY. And, as > linklocal all-nodes is ALREADY excempted from the MLD, what is left is > *ONLY* the solicited node multicast. I vote that, it too is exempted. > > When is this joined? ONLY when node configures a NEW id for address, > so what we are seeing on link, is two back-to-back messages: > > 1) join solicited node group (MLD), followed by > 2) ND DAD probe > > I just can't see any significant use for the (1), even for layer-2 > snooper. The probe alone carries exactly the same information as the > useless MLD join. And whats worse, the switch will increase the > probability of DAD "failing to do its suff"... (if it decides not to > forward the DAD to all links based on some stale soft state -- it > definetly cannot start querying at this point). The draft I've written attempts to make some use of the (possibly illogical) requirement that IPv6 nodes do MLD on Solicited Nodes Multicast in order to do DAD. here's the URL: http://www.ietf.org/internet-drafts/draft-daley-ipv6-mcast-dad-00.txt It allows an MLD router (the querier) to watch listener state on the network and respond to a report if that solicited nodes multicast address is not in use. (indicating that DAD is successful and the address is unique). It's not pretty, but it may be a the nearest thing to a significant use for this requirement. > Additionally, when ND is protected by IPSEC, the switch needs to do > the IPSEC also. > > >> - at least it should be optional for link local multicast groups used >> in Neighbor discovery >> >>=> I can't see how it can be optional: either it is useful so is >>recommended/required, or it is not useful so is not >>recommended/required. > > > Right, I'm requesting it to be at least optional. I don't think it > (MLD for link local ND groups) is useful for anything. As far as I can see, Optional doesn't really help, if there are some nodes doing MLD for DAD and others aren't there will never be applications which can rely on it (so the situation is self perpetuating...;) > >> - illogical definition: you cannot join solicited nodes multicast >> group before you have address, >> >>=> I don't understand: I can send a join message. > > > Yes, with "::" source address. Kinky.. :) > I don't really see why you can't send from a tentative address in this case. There are no responses being sent to unicast L3 addresses (and none off link). using "::" means that anyone else listening to your MLD report (existing nodes/routers) will ignore it. [cut section about l2snooping] > > Where did I say "multicast sucks". I definitely like multicast, I'm > just talking about these link local groups here, and specifically > about ND discovery part of it. If you can get MLD for link-scope multicast addresses removed, please do it entirely. It doesn't help anyone to have half a standard. Greg Daley -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 4 00:02:02 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g84722wf027483; Wed, 4 Sep 2002 00:02:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g84721tn027482; Wed, 4 Sep 2002 00:02:01 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8471lwf027467; Wed, 4 Sep 2002 00:01:47 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8471kPG027199; Wed, 4 Sep 2002 00:01:47 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.97.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA20410; Wed, 4 Sep 2002 01:01:22 -0600 (MDT) Received: from delta.cs.mu.OZ.AU ([172.30.0.189]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g846wpg19579; Wed, 4 Sep 2002 13:58:57 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g846rZu03115; Wed, 4 Sep 2002 13:54:15 +0700 (ICT) From: Robert Elz To: Markku Savela cc: Francis.Dupont@enst-bretagne.fr, itojun@iijlab.net, mrw@windriver.com, Erik.Nordmark@Sun.COM, dthaler@windows.microsoft.com, charliep@iprg.nokia.com, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] RE: RFC 2462 DAD optimization In-Reply-To: <200209031727.UAA16876@burp.tkv.asdf.org> References: <200209031727.UAA16876@burp.tkv.asdf.org> <200209031654.g83Gsj6o054279@givry.rennes.enst-bretagne.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 04 Sep 2002 13:53:35 +0700 Message-ID: <3113.1031122415@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 3 Sep 2002 20:27:22 +0300 From: Markku Savela Message-ID: <200209031727.UAA16876@burp.tkv.asdf.org> | ...and which totally bogus, as such switch cannot utilize the | information in any significant way. Huh??? Perhaps we can step back and look at what is going on here. When we have a multicast address, it is being sent to perhaps multiple (but usually not all) nodes on a link. When we have a link implemented by a switch, it (often) learns what addresses are on each port (by noting the source MAC addr) and only sends packets to the ports where an address occurs. Since nothing is ever sent from a multicast address, and since it can live on multiple ports (unlike a unicast address) it wouldn't matter if something was, the switch can't use that method to work out which ports a packet to a multicast address should be sent to. It then has two choices - either send the packet to everyone, which turns it (almost) into a broadcast, which we're trying to get away from, or create some new protocol by which nodes notify the switch of the multicast addresses they want sent to them. So, let's assume for now that the latter has been done, because we don't want multicast packets sent everywhere (normally). Whenever a node joins a multicast address, it engages in this link level protocol so the switches can learn which multicast address goes where. Now there's also the IP level multicast - the routers also (in general) need to know which links multicast packets need to be sent to, so at the IP level there's the MLD protocol by which a node informs a router that packets for some (IP level) multicast address should be sent to it (or really, just sent to the link where the node resides). So, when a node joins a multicast address it needs to engage in the MLD protocol to allow the routers to find out what is going on. So, for every (general) multicast address, the node would have to run two protocols, the link level one, and the IP level one, so all the right devices know where multicast packets should get sent. That's dumb - the two of them convey essntially the same information (especially when viewed from the point of view of the relevant receiver, with the other knowledge it has - the router knows which link by the link the packet is received from, the switch knows which port by the port the packet is received from). So, rather than use two protocols, the switch and the router both just use the contents of one packet, and get their information from that. You can call this a "layer violation" if you like, but this isn't unusual, we do lots of "layer violations" in the name of efficiency (I don't see you refusing to implement the TCP pseudo-header for example, but that's a layer violation too...) Now, in the special case of link local multicast, the router level (IP) protocol isn't useful for anything - the routers know which link a link level multicast belongs on (the link it is sent on, and nothing else), so no IP level protocol is needed for this particular case. But the link level protocol still is, and as the link level protocol is using the same packet formats as the IP level protocol (the same exact content) it still needs to get sent. You can (if you want to) just consider this a link level protocol, with a strange packet format - but it is required for the switches to be able to do some kind of sane multicast filtering. And given that the particular multicast packets are ones which usually should go nowhere, it really is an advantage to have them filtered, rather than broadcast. Just send the MLD packets, like the spec says. 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 Sep 4 00:37:17 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g847bHwf027628; Wed, 4 Sep 2002 00:37:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g847bGlm027627; Wed, 4 Sep 2002 00:37:16 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g847b3wf027609; Wed, 4 Sep 2002 00:37:03 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g847b3PG004975; Wed, 4 Sep 2002 00:37:03 -0700 (PDT) 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 BAA27715; Wed, 4 Sep 2002 01:36:56 -0600 (MDT) 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 g847aqh12200; Wed, 4 Sep 2002 09:36:52 +0200 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 JAA25019; Wed, 4 Sep 2002 09:36:52 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id g847ao6o056250; Wed, 4 Sep 2002 09:36:50 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200209040736.g847ao6o056250@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Markku Savela cc: itojun@iijlab.net, mrw@windriver.com, Erik.Nordmark@Sun.COM, kre@munnari.OZ.AU, dthaler@windows.microsoft.com, charliep@iprg.nokia.com, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] RE: RFC 2462 DAD optimization In-reply-to: Your message of Tue, 03 Sep 2002 20:27:22 +0300. <200209031727.UAA16876@burp.tkv.asdf.org> Date: Wed, 04 Sep 2002 09:36:49 +0200 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 no reason for using MLD for link local multicast groups > as far IPv6 (layer-3) is concerned. > > => there is a very well known reason: snooping by layer-2 switches. ...and which totally bogus, as such switch cannot utilize the information in any significant way. => it can use it as for any other multicast group. Don't forget the layer-2 snooping is a MLD function, NOT a ND one. Remember, I'm talking about LINK LOCAL MULTICAST groups used in IPv6 NEIGHTBOR DISCOVERY. => there is no reason to do a special case for them as the standard code which handles any multicast works well with them. And, as linklocal all-nodes is ALREADY excempted from the MLD, => this group is special (for MLD) and more, as all nodes by definition listen it, it should never be filtered out where there is an IPv6 node. what is left is *ONLY* the solicited node multicast. I vote that, it too is exempted. => I vote against. When is this joined? ONLY when node configures a NEW id for address, so what we are seeing on link, is two back-to-back messages: 1) join solicited node group (MLD), followed by 2) ND DAD probe I just can't see any significant use for the (1), even for layer-2 snooper. The probe alone carries exactly the same information as the useless MLD join. => the layer-2 snooper has nothing to do with ND, it handles only MLD. I believe your idea is add a ND snooping in place of the current reuse of MLD snooping is not good because it will introduce an unneeded exception. And whats worse, the switch will increase the probability of DAD "failing to do its suff"... (if it decides not to forward the DAD to all links based on some stale soft state -- it definetly cannot start querying at this point). => I don't buy this point. Additionally, when ND is protected by IPSEC, the switch needs to do the IPSEC also. => so MLD snooping is better? > - illogical definition: you cannot join solicited nodes multicast > group before you have address, > > => I don't understand: I can send a join message. Yes, with "::" source address. Kinky.. :) => I can't see a problem with the "::" source address in this case and for the layer-2 snooper the IPv6 source address is not useful. > - if layer-2 snoop is going to make use of MLD, it or some part of it > must actually be node on the network > > => no, the layer-2 snooper is a layer-2 snooper by definition. Then it cannot send queries, and it's knowledge about solicited node groups is totally "soft", practically useless (unless it snoops other ND traffic, in which case it doesn't need MLD at all for those). => actual experience (i.e., when a switch is not ultra cheap, it supports layer-2 snooping for multicast pruning) shows you are wrong. > => s/would add/adds/ because MLD is mandatory. But you still can remove > the support of multicast on the links (and remove MLD too). Perhaps > this is the best solution if your argument is that multicast just sucks. Where did I say "multicast sucks". I definitely like multicast, I'm just talking about these link local groups here, and specifically about ND discovery part of it. => if you like multicast why you want to do a very special case for ND when the IGMP/MLD snooping works well? I don't understand... Regards Francis.Dupont@enst-bretagne.fr PS: this discussion should not be in the mobile ip list: the magma list seems far 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 Sep 4 04:40:41 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g84Befwf028318; Wed, 4 Sep 2002 04:40:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g84Beese028315; Wed, 4 Sep 2002 04:40:40 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g84BeXwf028299 for ; Wed, 4 Sep 2002 04:40:34 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g84BeYuH012332 for ; Wed, 4 Sep 2002 04:40:35 -0700 (PDT) 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 FAA09084 for ; Wed, 4 Sep 2002 05:40:27 -0600 (MDT) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id OAA17884; Wed, 4 Sep 2002 14:39:08 +0300 Date: Wed, 4 Sep 2002 14:39:08 +0300 Message-Id: <200209041139.OAA17884@burp.tkv.asdf.org> From: Markku Savela To: kre@munnari.OZ.AU CC: ipng@sunroof.eng.sun.com In-reply-to: <3113.1031122415@munnari.OZ.AU> (message from Robert Elz on Wed, 04 Sep 2002 13:53:35 +0700) Subject: Re: RFC 2462 DAD optimization References: <200209031727.UAA16876@burp.tkv.asdf.org> <200209031654.g83Gsj6o054279@givry.rennes.enst-bretagne.fr> <3113.1031122415@munnari.OZ.AU> 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: Robert Elz > Since nothing is ever sent from a multicast address, and since it can > live on multiple ports (unlike a unicast address) it wouldn't matter if > something was, the switch can't use that method to work out which ports > a packet to a multicast address should be sent to. Solicted node multicast group is an exception to "nothing is ever sent". - MLD join would only be used when node does DAD, e.g. sends (1) MLD join with src=:: (2) DAD probe with src=:: - for *ANY* other packet, that has src != ::, the source address implictly indicates the solicited node multicast group that this node belongs. If the switch is mucking around with MLD messages, it would not be a big deal for it to implicitly remember solicited node groups just by tracking the IPv6 source addresses used by the packets. Much more robust and better solution than relying the single MLD report before DAD, which might get lost anyway (or switch powered down temporarily). > So, for every (general) multicast address, the node would have to run > two protocols, the link level one, and the IP level one, so all the right > devices know where multicast packets should get sent. I don't see where the two different protocols come from. As explained, membership of solicited node multicast group is implicitly indicated by EACH packet the node sends. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 4 05:43:53 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g84Chqwf028800; Wed, 4 Sep 2002 05:43:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g84Chqvc028799; Wed, 4 Sep 2002 05:43:52 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g84Chlwf028792 for ; Wed, 4 Sep 2002 05:43:47 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g84ChmPG009788 for ; Wed, 4 Sep 2002 05:43:48 -0700 (PDT) Received: from cs.tut.fi (varis.cs.tut.fi [130.230.4.42]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA06291 for ; Wed, 4 Sep 2002 06:43:42 -0600 (MDT) Received: from kiuru.cs.tut.fi (daemon@kiuru.cs.tut.fi [130.230.4.18]) by cs.tut.fi (8.8.8/8.8.8) with ESMTP id PAA13403 for ; Wed, 4 Sep 2002 15:43:41 +0300 (EET DST) Received: (from hessu@localhost) by kiuru.cs.tut.fi (8.11.6+Sun/8.8.4) id g84ChfP00651; Wed, 4 Sep 2002 15:43:41 +0300 (EET DST) X-Authentication-Warning: kiuru.cs.tut.fi: hessu set sender to hessu@cs.tut.fi using -f To: ipng@sunroof.eng.sun.com Subject: Comments on draft-ietf-ipngwg-rfc2553bis-06.txt From: Heikki Vatiainen Date: 04 Sep 2002 15:43:40 +0300 Message-ID: Lines: 45 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Here are my comments about draft-ietf-ipngwg-rfc2553bis-06.txt On many pages, null (the C null pointer constant) is sometimes written as null and sometimes NULL. Also, the ASCII NUL terminated C strings have different written forms. Currently the text has at least these variants of null/NULL: o NULL pointer o NULL o null pointer o null terminated name o null-terminated string o null byte o null For clarity, maybe all C null pointers could be written as "NULL". When ASCII NUL byte terminated C strings are discussed, they could all be written as "null-terminated string(s)". On top of page 12, there is one instance of _SS_ALIGNMENT. This, I suppose, should be _SS_ALIGNSIZE. Also on page 12, in the example about struct sockaddr_storage on systems with "sa_len", "#define _SS_PAD2SIZE" does not include sizeof (uint8_t), the size of "ss_len" member. On page 18, the printf seems to lack at least \n" and possibly more. On page 19, the second paragraph from bottom, inet_ntop() is used as an example of a function using standard IPv6 text forms. Should this be inet_pton() since it, just like getaddrinfo, takes in character strings (page 26, first paragraph)? On page 22, it is said that freeaddrinfo() frees addrinfo lists with "any additional storage associated with those structures". I take this additional storage is memory pointed by ai_addr and ai_canonname (unless ai_canonname points to the same place as nodename parameter)? Maybe the wording could be made explicit that after freeaddrinfo() is called, the caller MUST not refer to memory pointed by ai_addr members of freed addrinfo structures. The same applies to ai_cannoname if ai_canonname did not point to nodename. -- Heikki Vatiainen * hessu@cs.tut.fi Tampere University of Technology * Tampere, Finland -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 4 05:49:05 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g84Cn5wf028834; Wed, 4 Sep 2002 05:49:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g84Cn5p2028833; Wed, 4 Sep 2002 05:49:05 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g84Cmwwf028820 for ; Wed, 4 Sep 2002 05:48:58 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g84Cn0uH029141 for ; Wed, 4 Sep 2002 05:49:00 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.97.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA11016 for ; Wed, 4 Sep 2002 05:48:37 -0700 (PDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g84Clrg17977; Wed, 4 Sep 2002 19:47:59 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g84CjDc01634; Wed, 4 Sep 2002 19:45:13 +0700 (ICT) From: Robert Elz To: Markku Savela cc: ipng@sunroof.eng.sun.com Subject: Re: RFC 2462 DAD optimization In-Reply-To: <200209041139.OAA17884@burp.tkv.asdf.org> References: <200209041139.OAA17884@burp.tkv.asdf.org> <200209031727.UAA16876@burp.tkv.asdf.org> <200209031654.g83Gsj6o054279@givry.rennes.enst-bretagne.fr> <3113.1031122415@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 04 Sep 2002 19:45:12 +0700 Message-ID: <1632.1031143512@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 4 Sep 2002 14:39:08 +0300 From: Markku Savela Message-ID: <200209041139.OAA17884@burp.tkv.asdf.org> | I don't see where the two different protocols come from. As explained, | membership of solicited node multicast group is implicitly indicated | by EACH packet the node sends. This only works if the node actually sends a packet (from that address). For unicast, there's no problem, as if a unicast (MAC) address is unknown, the packet can just be flooded by the switch. Usually that packet will elicit a response, and that response will allow the relevant port to be found, so the flooding is rare. But that doesn't happen with multicast, there are no responses, so "just flood" by itself would never cease (and in any case, it needs to be able to get to multiple places). I suppose that switches could build a bunch of extra magic, to try and fathom where to send solicited node multicast packets (which would mean that it would need to recognise them, which means peering into the L3 headers of every multicast packet, as the ethernet multicast addr certainly won't tell it for certain), but it really is much simpler for the switch to just do the same things for these multicasts as just about all others ("all nodes" is different, because by definition, that's supposed to go everywhere - note that "all routers" isn't excluded from MLD I don't think). The cost is the need to send a packet. That's done normally when adding a multicast addr to an interface, so the code is there anyway (or should be) - to not send one when the multicast addr happens to be a solicited node addr would seem to take extra code (though of course, this kind of thing tends to depend upon the implementation). 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 Sep 4 07:00:45 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g84E0iwf029581; Wed, 4 Sep 2002 07:00:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g84E0itI029580; Wed, 4 Sep 2002 07:00:44 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g84E0cwf029573 for ; Wed, 4 Sep 2002 07:00:39 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g84E0cPG002588 for ; Wed, 4 Sep 2002 07:00:39 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA13212 for ; Wed, 4 Sep 2002 07:00:33 -0700 (PDT) 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 g84Drah23840; Wed, 4 Sep 2002 15:53:36 +0200 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 PAA29956; Wed, 4 Sep 2002 15:53:37 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id g84Dra6o057592; Wed, 4 Sep 2002 15:53:36 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200209041353.g84Dra6o057592@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Markku Savela cc: kre@munnari.OZ.AU, ipng@sunroof.eng.sun.com Subject: Re: RFC 2462 DAD optimization In-reply-to: Your message of Wed, 04 Sep 2002 14:39:08 +0300. <200209041139.OAA17884@burp.tkv.asdf.org> Date: Wed, 04 Sep 2002 15:53:36 +0200 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: Solicted node multicast group is an exception to "nothing is ever sent". - MLD join would only be used when node does DAD, e.g. sends (1) MLD join with src=:: (2) DAD probe with src=:: - for *ANY* other packet, that has src != ::, the source address implictly indicates the solicited node multicast group that this node belongs. => wrong, first ND router solicits are usually sent from the :: source address. 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 Sep 4 07:11:26 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g84EBQwf029693; Wed, 4 Sep 2002 07:11:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g84EBP3o029692; Wed, 4 Sep 2002 07:11:25 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g84EBKwf029685 for ; Wed, 4 Sep 2002 07:11:20 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g84EBKuH028524 for ; Wed, 4 Sep 2002 07:11:21 -0700 (PDT) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA18785 for ; Wed, 4 Sep 2002 08:11:11 -0600 (MDT) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id RAA18085; Wed, 4 Sep 2002 17:10:11 +0300 Date: Wed, 4 Sep 2002 17:10:11 +0300 Message-Id: <200209041410.RAA18085@burp.tkv.asdf.org> From: Markku Savela To: kre@munnari.OZ.AU CC: ipng@sunroof.eng.sun.com In-reply-to: <1632.1031143512@munnari.OZ.AU> (message from Robert Elz on Wed, 04 Sep 2002 19:45:12 +0700) Subject: Re: RFC 2462 DAD optimization References: <200209041139.OAA17884@burp.tkv.asdf.org> <200209031727.UAA16876@burp.tkv.asdf.org> <200209031654.g83Gsj6o054279@givry.rennes.enst-bretagne.fr> <3113.1031122415@munnari.OZ.AU> <1632.1031143512@munnari.OZ.AU> 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: Robert Elz > > Date: Wed, 4 Sep 2002 14:39:08 +0300 > From: Markku Savela > Message-ID: <200209041139.OAA17884@burp.tkv.asdf.org> > > | I don't see where the two different protocols come from. As explained, > | membership of solicited node multicast group is implicitly indicated > | by EACH packet the node sends. > > This only works if the node actually sends a packet (from that address). Such node will then only receive linklocal multicast (or is in promiscuous mode) without ever sending anything. Such node doesn't really need address at all, it can even skip the DAD. > I suppose that switches could build a bunch of extra magic, to try and > fathom where to send solicited node multicast packets (which would mean > that it would need to recognise them, which means peering into the L3 > headers of every multicast packet, If it snoops MLD, it has to peek into L3 and deeper (locate ICMP header after potential sequence of extension headers) for every multicast packet anyways. Looking at IPv6 source address is trivial compared to this (it's always in the same fixed position). > The cost is the need to send a packet. That's done normally when adding > a multicast addr to an interface, so the code is there anyway (or should > be) - to not send one when the multicast addr happens to be a solicited > node addr would seem to take extra code (though of course, this kind of > thing tends to depend upon the implementation). Exactly, when implementing IPv6, there was no logical reason to do MLD for link local groups. Additional consideration: if solicited-node groups are true part of MLD, then one should note that MLD query with ANY group will elicit responce from almost every node on the link (as I assume high probability that the solicited node groups usually have only one or few hosts each). How many nodes are on the link? Will some reports be lost? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 4 07:15:40 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g84EFewf029725; Wed, 4 Sep 2002 07:15:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g84EFemb029724; Wed, 4 Sep 2002 07:15:40 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g84EFYwf029717 for ; Wed, 4 Sep 2002 07:15:34 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g84EFTPG008316 for ; Wed, 4 Sep 2002 07:15:34 -0700 (PDT) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA20229 for ; Wed, 4 Sep 2002 08:15:20 -0600 (MDT) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id RAA18098; Wed, 4 Sep 2002 17:15:08 +0300 Date: Wed, 4 Sep 2002 17:15:08 +0300 Message-Id: <200209041415.RAA18098@burp.tkv.asdf.org> From: Markku Savela To: Francis.Dupont@enst-bretagne.fr CC: kre@munnari.OZ.AU, ipng@sunroof.eng.sun.com In-reply-to: <200209041353.g84Dra6o057592@givry.rennes.enst-bretagne.fr> (message from Francis Dupont on Wed, 04 Sep 2002 15:53:36 +0200) Subject: Re: RFC 2462 DAD optimization References: <200209041353.g84Dra6o057592@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 > In your previous mail you wrote: > > Solicted node multicast group is an exception to "nothing is ever sent". > > - MLD join would only be used when node does DAD, e.g. sends > > (1) MLD join with src=:: > (2) DAD probe with src=:: > > - for *ANY* other packet, that has src != ::, the source address > implictly indicates the solicited node multicast group that this > node belongs. > > => wrong, first ND router solicits are usually sent from the :: source > address. Yes, should have remembered that. Mine does that, I wonder if that is the only one with this feature.. :-) But, for any other useful traffic, the source address is there, and implicitly defines the group. A snooping switch would be foolish not to utilize this easily available info for updating it's soft state. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 4 08:36:55 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g84Fatwf000301; Wed, 4 Sep 2002 08:36:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g84FasYw000300; Wed, 4 Sep 2002 08:36:54 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g84Fanwf000293 for ; Wed, 4 Sep 2002 08:36:49 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g84FaoPG008620 for ; Wed, 4 Sep 2002 08:36:50 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.97.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA11131 for ; Wed, 4 Sep 2002 09:35:07 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g84FY7g00894; Wed, 4 Sep 2002 22:34:07 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g84FVOc02394; Wed, 4 Sep 2002 22:31:24 +0700 (ICT) From: Robert Elz To: Markku Savela cc: ipng@sunroof.eng.sun.com Subject: Re: RFC 2462 DAD optimization In-Reply-To: <200209041410.RAA18085@burp.tkv.asdf.org> References: <200209041410.RAA18085@burp.tkv.asdf.org> <200209041139.OAA17884@burp.tkv.asdf.org> <200209031727.UAA16876@burp.tkv.asdf.org> <200209031654.g83Gsj6o054279@givry.rennes.enst-bretagne.fr> <3113.1031122415@munnari.OZ.AU> <1632.1031143512@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 04 Sep 2002 22:31:24 +0700 Message-ID: <2392.1031153484@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 4 Sep 2002 17:10:11 +0300 From: Markku Savela Message-ID: <200209041410.RAA18085@burp.tkv.asdf.org> | Such node will then only receive linklocal multicast (or is in | promiscuous mode) without ever sending anything. Such node doesn't | really need address at all, it can even skip the DAD. No, you missed the point - the node doesn't send until after it has received. It can't receive until someone does ND for one of its addresses. To receive the ND packet, it must receive a multicast to the solicited node multicast address (if I have the correct expression there). That is, multicast has to work before packets are transmitted. | If it snoops MLD, it has to peek into L3 and deeper (locate ICMP | header after potential sequence of extension headers) for every | multicast packet anyways. Yes, but that it is already doing. That's part of the design, and can't be avoided (while not flooding multicast packets). But: | Looking at IPv6 source address is trivial | compared to this (it's always in the same fixed position). Yes, it is easier, but it is additional. And it requires that the packet actually be sent to be snooped. I guess you could always just require that a node send some random packet (from every address - or at least every one that results in a different multicast address) when it assigns the address (joins the multicast group), but if you're going to require that, why not just make it be a MLD packet? | Exactly, when implementing IPv6, there was no logical reason to do MLD | for link local groups. But there is, you just didn't see it. That's what is being explained. The spec is clear though, I think. | Additional consideration: if solicited-node groups are true part of | MLD, then one should note that MLD query with ANY group will elicit | responce from almost every node on the link (as I assume high | probability that the solicited node groups usually have only one or | few hosts each). How many nodes are on the link? Will some reports be | lost? Who cares? Remember these particular packets are only being used, as I understand it, for the benefit of the switches. They achieve nothing useful at the multicast routing level. As long as your switch sees the join (and it is the thing at the other end of the wire from you), then it can do the right thing. I'm not sure why anyone would be sending a query for one of those, just the join (but the multicast protocols themselves are perhaps beyond my understanding, so I might be missing some other potential 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 Wed Sep 4 10:29:41 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g84HTewf001251; Wed, 4 Sep 2002 10:29:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g84HTeJI001250; Wed, 4 Sep 2002 10:29:40 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g84HTZwf001243 for ; Wed, 4 Sep 2002 10:29:35 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g84HTZuH023417 for ; Wed, 4 Sep 2002 10:29:35 -0700 (PDT) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA14086 for ; Wed, 4 Sep 2002 11:29:29 -0600 (MDT) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id UAA18398; Wed, 4 Sep 2002 20:27:33 +0300 Date: Wed, 4 Sep 2002 20:27:33 +0300 Message-Id: <200209041727.UAA18398@burp.tkv.asdf.org> From: Markku Savela To: kre@munnari.OZ.AU CC: ipng@sunroof.eng.sun.com In-reply-to: <2392.1031153484@munnari.OZ.AU> (message from Robert Elz on Wed, 04 Sep 2002 22:31:24 +0700) Subject: Re: RFC 2462 DAD optimization References: <200209041410.RAA18085@burp.tkv.asdf.org> <200209041139.OAA17884@burp.tkv.asdf.org> <200209031727.UAA16876@burp.tkv.asdf.org> <200209031654.g83Gsj6o054279@givry.rennes.enst-bretagne.fr> <3113.1031122415@munnari.OZ.AU> <1632.1031143512@munnari.OZ.AU> <2392.1031153484@munnari.OZ.AU> 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: Robert Elz > No, you missed the point - the node doesn't send until after it > has received. It can't receive until someone does ND for one of > its addresses. To receive the ND packet, it must receive a > multicast to the solicited node multicast address (if I have the > correct expression there). That is, multicast has to work before > packets are transmitted. The node is listening the solicited node (just has not sent MLD on it). On a link without this switch, things work fine. With switch, it would have to recognize the DAD probe. > | Additional consideration: if solicited-node groups are true part of > | MLD, then one should note that MLD query with ANY group will elicit > | responce from almost every node on the link (as I assume high > | probability that the solicited node groups usually have only one or > | few hosts each). How many nodes are on the link? Will some reports be > | lost? > > Who cares? Remember these particular packets are only being used, as > I understand it, for the benefit of the switches. They achieve nothing > useful at the multicast routing level. As long as your switch sees the > join (and it is the thing at the other end of the wire from you), then > it can do the right thing. I'm not sure why anyone would be sending a > query for one of those, just the join (but the multicast protocols themselves > are perhaps beyond my understanding, so I might be missing some other > potential use). Ahh, but you are missing something: if the switch is booted, you definitely do not want to require, that EVERY NODE on the link must be rebooted after the switch. Before the switch can start applying the collected state, it MUST have complete state of the active multicast groups on the link. Until it has complete information, it must pass all multicast groups to the link. The *ONLY* way for switch to arrive into complete state after powerup is to 1) watch for (or generate) a query for ANY multicast group, set a mark 2) record ALL reports resulting from the query, and new joins 3) when it thinks ALL reports have arrived, it may perhaps assume it has complete state, and continue maintaining it by watching the joins. For the switch to work on link local solicited groups, it MUST rely on ANY query. Unless, you want to change the ND so that MLD on solicited nodes must be periodically re-sent by each 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 Wed Sep 4 12:08:29 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g84J8Swf001558; Wed, 4 Sep 2002 12:08:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g84J8SPY001557; Wed, 4 Sep 2002 12:08:28 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g84J8Lwf001549; Wed, 4 Sep 2002 12:08:21 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g84J8MuH008409; Wed, 4 Sep 2002 12:08:22 -0700 (PDT) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA04552; Wed, 4 Sep 2002 12:08:17 -0700 (PDT) Received: from kenawang (dhcp10-6.isi.com [10.30.10.216]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id MAA21296; Wed, 4 Sep 2002 12:06:19 -0700 (PDT) Message-Id: <4.2.2.20020904092927.02b12770@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 04 Sep 2002 09:31:12 -0400 To: Markku Savela From: Margaret Wasserman Subject: Re: [mobile-ip] RE: RFC 2462 DAD optimization Cc: Francis.Dupont@enst-bretagne.fr, itojun@iijlab.net, Erik.Nordmark@Sun.COM, kre@munnari.OZ.AU, dthaler@windows.microsoft.com, charliep@iprg.nokia.com, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com In-Reply-To: <200209031727.UAA16876@burp.tkv.asdf.org> References: <200209031654.g83Gsj6o054279@givry.rennes.enst-bretagne.fr> <200209031654.g83Gsj6o054279@givry.rennes.enst-bretagne.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi All, The update to IGMPv3/MLDv2 that Francis mentioned is being developed by the magma WG. So, it would probably be most productive to move the discussion of how/if to join link-local multicast groups to the magma list. 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 Wed Sep 4 12:14:40 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g84JEewf001614; Wed, 4 Sep 2002 12:14:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g84JEe5b001613; Wed, 4 Sep 2002 12:14:40 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g84JEYwf001606; Wed, 4 Sep 2002 12:14:34 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g84JEVPG021159; Wed, 4 Sep 2002 12:14:31 -0700 (PDT) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA08862; Wed, 4 Sep 2002 12:14:25 -0700 (PDT) Received: from kenawang (dhcp10-6.isi.com [10.30.10.216]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id MAA25394; Wed, 4 Sep 2002 12:12:39 -0700 (PDT) Message-Id: <4.2.2.20020904092927.02b12770@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 04 Sep 2002 09:31:12 -0400 To: Markku Savela From: Margaret Wasserman Subject: Re: [mobile-ip] RE: RFC 2462 DAD optimization Cc: Francis.Dupont@enst-bretagne.fr, itojun@iijlab.net, Erik.Nordmark@Sun.COM, kre@munnari.OZ.AU, dthaler@windows.microsoft.com, charliep@iprg.nokia.com, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com In-Reply-To: <200209031727.UAA16876@burp.tkv.asdf.org> References: <200209031654.g83Gsj6o054279@givry.rennes.enst-bretagne.fr> <200209031654.g83Gsj6o054279@givry.rennes.enst-bretagne.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi All, The update to IGMPv3/MLDv2 that Francis mentioned is being developed by the magma WG. So, it would probably be most productive to move the discussion of how/if to join link-local multicast groups to the magma list. 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 Sat Sep 7 08:31:07 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g87FV7wf015860; Sat, 7 Sep 2002 08:31:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g87FV7cj015859; Sat, 7 Sep 2002 08:31:07 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g87FV1wf015852 for ; Sat, 7 Sep 2002 08:31:01 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g87FV5PG029169 for ; Sat, 7 Sep 2002 08:31:05 -0700 (PDT) Received: from wira1.cs.usm.my (wira1.cs.usm.my [161.142.8.21]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA13084 for ; Sat, 7 Sep 2002 08:30:59 -0700 (PDT) Received: from LiuXiaoLian ([161.142.8.198]) by wira1.cs.usm.my (8.12.2/8.12.2) with ESMTP id g87FU8T0014664; Sat, 7 Sep 2002 23:30:11 +0800 (SGT) From: "Liu xiao lian" To: Cc: , "'vasuki ponnusamy'" Subject: Comment on RFC 1981-Path MTU Discovery for IPV6 Date: Sat, 7 Sep 2002 23:26:37 +0800 Message-ID: <000001c25682$f5be6cb0$c6088ea1@LiuXiaoLian> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C256C6.03E1ACB0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C256C6.03E1ACB0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Referring to item 5.3, we think that the timestamp value need not be set to "Reserved". This is because we can just use the timestamp and the current time to determine that the PMTU has expired. For example, before sending out a packet, the timer-based procedure should check whether the PMTU to be used has expired based on the cached timestamp and current time. If it has expired indeed, then there are no packets should be sent out using this PMTU. The PMTU value should be reset to the MTU value of the first hop and the PMTU discovery should be restarted. We think the "Reserved" value can be removed to make the process of detemining the stale PMTUs less complicated. We welcome suggestions and comments. XiaoLian LIU Computer Science School USM 11800 Pulau Penang Malaysia ------=_NextPart_000_0001_01C256C6.03E1ACB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Comment on RFC 1981-Path MTU Discovery for IPV6

Referring to item 5.3, we think that the timestamp value need not = be set to "Reserved".

This is because we can just use the timestamp and the current time = to determine that the PMTU = has expired.  For example, before sending out a packet, the = timer-based procedure should check whether the PMTU to be used has = expired based on the cached timestamp and current time.  If it has = expired indeed, then there are no packets should be sent out using this PMTU.  The PMTU value should be reset to the MTU = value of the first hop and the PMTU discovery should be = restarted.

We think the "Reserved" value can be removed to make the = process of detemining the stale PMTUs less = complicated.

We welcome suggestions and comments.



XiaoLian = LIU

Computer Science School

USM 11800

Pulau Penang

Malaysia

------=_NextPart_000_0001_01C256C6.03E1ACB0-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 7 12:17:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g87JHWwf016348; Sat, 7 Sep 2002 12:17:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g87JHWjK016347; Sat, 7 Sep 2002 12:17:32 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g87JHRwf016340 for ; Sat, 7 Sep 2002 12:17:27 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g87JHVht016944 for ; Sat, 7 Sep 2002 12:17:31 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA27975 for ; Sat, 7 Sep 2002 12:17:25 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g87JHOV19022 for ; Sat, 7 Sep 2002 22:17:24 +0300 Date: Sat, 7 Sep 2002 22:17:23 +0300 (EEST) From: Pekka Savola To: ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-ietf-ipv6-tunnel-v02-00.txt In-Reply-To: <200207241208.IAA02219@ietf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk A few comments. On Wed, 24 Jul 2002 Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the IP Version 6 Working Group Working Group of the IETF. > > Title : Generic Packet Tunneling in IPv6 Specification > Author(s) : A. Conta, S. Deering > Filename : draft-ietf-ipv6-tunnel-v02-00.txt > Pages : 37 > Date : 23-Jul-02 > > This document defines the model and generic mechanisms for IPv6 > encapsulation of Internet packets, such as IPv6 and IPv4. The model > and mechanisms can be applied to other protocol packets as well, such > as AppleTalk, IPX, CLNP, or others. Generic comments. 1) Compare a bit to transmech-v2/RFC1853 (IPIP) tunneling which seem to be quite self-sufficient. This seems to be quite (overly?) verbose. But I guess there's no use throwing out already written text.. 2) Tunnel Encapsulation Limit (e.g. 4.1, 4.1.3, 5.1 second paragraph, 7 Note) is not implemented that I'm aware of --> remove? 3) What's the implementation status of relaying tunnel ICMP messages (section 8.1), I wonder? 4) A couple of potential security considerations areas come to mind: - threats due to processing of ICMP messages (e.g. attacker sends uncalled-for unreachable/hop-limit exceeded/parameter problem messages). This is new only for ICMP message relaying (sect 8.1), possibility to hide the source of attacks? A pointer to general ICMP consideratins for this? - problems due to different trust models in tunnel endpoints. As tunnel endpoint is can be reached with "link-local" messages, at least the other end point has about the same security requirements as a node on a local physical link. Especially in the case of tunnel crossing from one organization to another, or "wildcard (no configured other endpoint) decapsulator" (e.g. automatic tunneling kind-of open-ended tunnel). Specific comments. 1) 6.4 IPv6 Tunnel Packet Traffic Class The IPv6 Tunnel Packet Traffic Class indicates the value that a tunnel entry-point node sets in the Traffic Class field of a tunnel header. The default value is zero. The configured Packet Traffic Class can also indicate whether the value of the Traffic Class field in the tunnel header is copied from the original header, or it is set to the pre-configured value. 6.5 IPv6 Tunnel Flow Label The IPv6 Tunnel Flow Label indicates the value that a tunnel entry- point node sets in the flow label of a tunnel header. The default value is zero. ==> I think at least in the case traffic class, there's some new specification for handling the bits (see similar thread for transmech-v2) 2) 6.7 IPv6 Tunnel MTU The tunnel MTU is set dynamically to the Path MTU between the tunnel entry-point and the tunnel exit-point nodes, minus the size of the tunnel headers: the maximum size of a tunnel packet payload that can be sent through the tunnel without fragmentation [IPv6-Spec]. The tunnel entry-point node performs Path MTU discovery on the path between the tunnel entry-point and exit-point nodes [PMTU-Spec], [ICMP-Spec]. The tunnel MTU of a nested tunnel is the tunnel MTU of [...] ==> reword; PMTUD is not necessarily always performed. -- 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 Sep 7 12:24:40 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g87JOdwf016422; Sat, 7 Sep 2002 12:24:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g87JOdvK016421; Sat, 7 Sep 2002 12:24:39 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g87JOXwf016411 for ; Sat, 7 Sep 2002 12:24:33 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g87JObht021722 for ; Sat, 7 Sep 2002 12:24:37 -0700 (PDT) Received: from smtp5.jaring.my (smtp5.jaring.my [61.6.32.55]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA12219 for ; Sat, 7 Sep 2002 13:24:31 -0600 (MDT) Received: from linda (j51.sja2.jaring.my [161.142.162.65]) by smtp5.jaring.my (8.11.4/8.11.4) with SMTP id g87JOLW04323; Sun, 8 Sep 2002 03:24:22 +0800 (MYT) Message-ID: <002901c256a5$09d5e300$41a28ea1@linda> From: "Linda" To: Cc: "alan chew" , , , , , Subject: Comment on RFC 2485-DHCP Option for The Open Group's User Authentication Protocol Date: Sun, 8 Sep 2002 03:30:26 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0026_01C256E8.12DD7560" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0026_01C256E8.12DD7560 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable In reference to RFC 2485, I would like to suggest some alternatives to = the things written. In the last section of User Authentication Protocol Option=20 "URL list A list of one or more URLs separated by the ASCII = space character (0x20)." 1. Instead of ASCII space character, we should use square brackets [ ] = to determine the next URL in the sequence. Space character is not = encouraged as most webservers today support space in URL. Other ASCII characters is not suitable for implementation is it might = also appear in the URL. To lessen the burden to the client to single out the URLs, we can = encapsulate each URL with square brackets, not replacing it. The url = should look something like this = :[http://www.yahoo.com][http://www.google.com]=20 2. Port identifier includes into the consideration of showing it to the = URL. By appending the port number at the end of the URL, eg: = [http://www.yahoo.com:80] we can enable the UAP to detemine the port in = an easier manner. Additional comments are welcome. Linda Lam Hooi School of Computer Science USM Penang, Malaysia ------=_NextPart_000_0026_01C256E8.12DD7560 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
In reference = to RFC=20 2485, I would like to suggest some alternatives to the things=20 written.

In the last section of User = Authentication=20 Protocol Option 

"URL=20 list           &nb= sp;=20 A list of one or more URLs separated by the = ASCII space=20 character (0x20)."


1. = Instead of=20 ASCII space character, we should use square brackets [ ] to determine = the next=20 URL in the   sequence. Space = character is not=20 encouraged as most webservers today support space in=20 URL.

Other ASCII characters is not = suitable for=20 implementation is it might also appear in the URL.

To lessen the burden to the client = to single=20 out the URLs, we can encapsulate each URL with square brackets, not = replacing=20 it. The url should look something like this=20 :[http://www.yahoo.com][http://www.google.com]

2. Port identifier includes into the consideration = of=20 showing it to the URL. By appending the port number at the end of the = URL, eg: [http://www.yahoo.com:80] we can enable the UAP to = detemine the=20 port in an easier manner.

Additional comments are welcome.

 

Linda Lam Hooi
School of Computer Science
USM Penang,
Malaysia
 
------=_NextPart_000_0026_01C256E8.12DD7560-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 7 12:31:56 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g87JVtwf016470; Sat, 7 Sep 2002 12:31:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g87JVtt7016469; Sat, 7 Sep 2002 12:31:55 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g87JVowf016462 for ; Sat, 7 Sep 2002 12:31:50 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g87JVsPG008948 for ; Sat, 7 Sep 2002 12:31:54 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA07351 for ; Sat, 7 Sep 2002 13:31:48 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g87JVd819151; Sat, 7 Sep 2002 22:31:40 +0300 Date: Sat, 7 Sep 2002 22:31:39 +0300 (EEST) From: Pekka Savola To: itojun@iijlab.net cc: ipng@sunroof.eng.sun.com Subject: v6mapped-harmful comments [Re: another input to IPv6 addressing architecture] In-Reply-To: <20020829231727.E283F4B22@coconut.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, A few comments on the draft. General: I agree that v4mapped on the wire is bad for many reasons, but how it could be removed / use simplified is a different thing. Content: 2. Threats due to the use of IPv4 mapped address on wire o By transmitting IPv6 packet with ::ffff:127.0.0.1 in IPv6 source address field, applications that assume basic API behavior will be tricked to believe that the packet is from the node itself (IPv4 loopback address, 127.0.0.1). ==> this would be partially fixed if the implementations were forced (by some mechanism) re-inject the packet to ip_input (or equivalent), not continue processing it locally. Then most harmful packets would be rejected as bogons. o By transmitting IPv6 packet to firewall device, with IPv4 mapped address corresponds to address inside the firewall (like ::ffff:10.1.1.1) as the IPv6 source address, malicious party could bypass IPv4 filtering rules and inject traffic inside the firewall. ==> This would be a bit more difficult to achieve with above means. 5.1. Kernel/library developers o Do not support IPv4 mapped address on AF_INET6 API (RFC2553 section 3.7). By doing so the kernel TCP/UDP code will be greatly simplified, and will reduce the likelihood of security-sensitive kernel bugs. ==> I don't think it's nice to advocate (at least, without any warning or more detailed text!) non-comliance with the API: many server-side dual-stack apps rely on this functionality to operate. If such support would be arbitrarily skipped, the dual-stack application would then continue to bind only to :: --> IPv6 and no longer v4. Smells like a huge operational problem. Editorial: Some of the translator technologies such as SIIT [Nordmark, 2000] uses ==> s/of the // ==> s/uses/use/ 4. Suggested protocol change ==> s/change/changes/ o Drop any IPv6 native packet with IPv4 mapped address in any of IPv6 ==> s/native // (or ..? -- I don't understand what native means there) o Drop any IPv6 DNS response that contains IPv4 mapped address. ==> "IPv6 DNS response" .. a bit ambiguous. do you mean AAAA response? On Fri, 30 Aug 2002 itojun@iijlab.net wrote: > i have another input to IPv6 addressing architecture, which is > very securty-sensitive. please review and integrate it before > publishing the next one. > draft-itojun-v6ops-v4mapped-harmful-00.txt > > itojun > > > --- > 4. Suggested protocol change > > o In IPv4 address architecture document [Hinden, 1998] explicitly state > that IPv4 mapped address is for use within basic API [Gilligan, 1999] > , and basic API only. Forbid any other uses. > > o Move any document that suggests the use of IPv4 mapped address on wire > to historic, due to security reasons. > > The above change will remove the threat due to the use of IPv4 mapped > address on wire. > > Another way is to deprecate RFC2553 section 3.7, however, due to the > wide deployment of applications that use IPv6 basic API, the option is > not feasible. > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Sep 7 13:02:55 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g87K2swf016633; Sat, 7 Sep 2002 13:02:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g87K2sjV016632; Sat, 7 Sep 2002 13:02:54 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g87K2nwf016625 for ; Sat, 7 Sep 2002 13:02:49 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g87K2sht027274 for ; Sat, 7 Sep 2002 13:02:54 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA18709 for ; Sat, 7 Sep 2002 14:02:48 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g87K2ln19368 for ; Sat, 7 Sep 2002 23:02:47 +0300 Date: Sat, 7 Sep 2002 23:02:46 +0300 (EEST) From: Pekka Savola To: ipng@sunroof.eng.sun.com Subject: comments on lcna-minreq-02 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk A few comments on lcna-minreq-02. 2.2.3 Anycast An LCNA might use the anycast address in some instances, e.g. DNS server discovery, but never assign anycast addresses to its own interface ([rfc2526]). [Note]: According to [rfc2373] section 2.6, anycast address is not assigned to a host, but discussion is still going on. ==> perhaps note can be removed, as it changes nothing. You can still specify that lcna does not do anycast even if 2373 was changed. 2.3 Examples of LCNA applications Here are several examples of LCNA usage models, especially for home network applications. ==> these should be moved to an appendix. 3.1.2 Routing Header [Sending] LCNAs may not originate Routing Header. ==> what do you mean by "may not"? (do not have to be able to?) [Receiving] As [rfc2460] regulates, the processing of segment_left as zero is unconditionally mandatory. ==> well, there's nothing to process, but LCNA has to be able to parse routing header, yes. If the Segment Left field has a non-zero value and RH type is zero, the LCNA SHOULD forward the packet to the next intermediate node, even when the node is a host. However, if the LCNA has limited resource, it can respond to this RH with parameter problem ICMP. ==> this has problems, see (hopefully) node reqs draft or draft-savola-ipv6-rh-hosts-00.txt 3.2 Path MTU Discovery for IP version 6 [rfc1981] When an implementation can guarantee that the sending packet size can be restricted to less than the IPv6 MINMTU ==> s/less than/less than or equal to/ 3.3 Neighbor Discovery for IP Version 6 (IPv6) [rfc2461] In this document, we assume that an LCNA has only one network Interface, but it does not prohibit multiple interfaces. When an LCNA is assumed to have multiple interfaces, the following must be considered requiring more resources. - Types of routing information (such as destination cache and routing table) - Number of cache entries will increase * ND cache * Default router list * Prefix list ==> are you making an implicit assumption that there couldn't be multiple prefixes advertised over one physical interface? 3.5 Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification [rfc2463] On LCNAs, ICMP used only by a router MAY be omitted (Table 2). ICMPs for Echo Request/Reply and minimum error reporting MUST be implemented. The necessary function for ICMPv6 may be added depending upon the finalization of Mobile IPv6 specification. An LCNA MUST have some mechanism for Rate limitation. ==> rate limitation of what? ICMP error messages (as noted by ICMPv6 spec) or for e.g. ICMP echo req/reply too? Table 2. Mandatory ICMP messages for LCNA ===============+===============================+========== Type Code Necessary? ===============+===============================+========== [...] 2: 0: Packet too big No Packet Too Big Message ==> if an LCNA receives a packet that's too big and can't process it, how would it react (it's able to deal with at least 1500 bytes right?)? 5.1 DNS Extensions to support IP version 6 [rfc1886] and IPv6 Stateless DNS Discovery [DDIS] If an LCNA is a passive node, it will not become an initiator of communication. This means that name resolution function MAY be omitted (the implementation of resolver can be omitted on a On the other hand, if an LCNA is an active node, DNS name resolution is necessary. In such cases, automatic DNS server discovery is important. On this topic, discussions are ongoing in IETF IPv6 WG. If a standard is finalized, it might become a mandatory item for LCNAs. AAAA is mandatory if an LCNA needs DNS name lookups. A6 record is currently proposed and discussed in IETF for an alternative to AAAA record. We need to check the progress. The IN6.ARPA. domain and nibble-style are mandatory if an LCNA needs DNS reverse name lookups. However, the IP6.INT. is more widely used than the IN6.ARPA. at this time. ==> I think the first paragraph is a bit out of sync; passive nodes may do DNS lookups (specifically, often reverse DNS lookups). -- 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 Sep 8 12:18:20 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g88JIKwf019664; Sun, 8 Sep 2002 12:18:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g88JIKG0019663; Sun, 8 Sep 2002 12:18:20 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g88JIEwf019656 for ; Sun, 8 Sep 2002 12:18:14 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g88JIJht012675 for ; Sun, 8 Sep 2002 12:18:19 -0700 (PDT) Received: from shen.bol.com.br (shen.bol.com.br [200.221.24.14]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA11065 for ; Sun, 8 Sep 2002 13:18:13 -0600 (MDT) From: rdfreita@bol.com.br Received: from bol.com.br (200.221.24.138) by shen.bol.com.br (5.1.071) id 3D63D22F005E6431 for ipng@sunroof.eng.sun.com; Sun, 8 Sep 2002 16:17:30 -0300 Date: Sun, 8 Sep 2002 16:16:24 -0300 Message-Id: Subject: Flow Label field - IPV6 MIME-Version: 1.0 Content-Type: text/plain;charset="iso-8859-1" To: ipng@sunroof.eng.sun.com X-XaM3-API-Version: 2.4.3.4.4 X-SenderIP: 200.192.35.5 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g88JIEwf019657 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi all, I have read the topic concerning the Flow label field in RFC2460 and it did not becames clear to me, eg.: how to implement it, internal values, etc... Please, I would appreciate if someone tell me where can i find detailed information of this field or send me it, if exist ! Thanks Reginaldo __________________________________________________________________________ AcessoBOL, só R$ 9,90! O menor preço do mercado! Assine já! http://www.bol.com.br/acessobol -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 8 21:56:23 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g894uMwf020654; Sun, 8 Sep 2002 21:56:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g894uMKZ020653; Sun, 8 Sep 2002 21:56:22 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g894uHwf020646 for ; Sun, 8 Sep 2002 21:56:17 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g894uLPG024809 for ; Sun, 8 Sep 2002 21:56:21 -0700 (PDT) Received: from md.swissinfo.org ([146.159.4.100]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA27007 for ; Sun, 8 Sep 2002 22:56:15 -0600 (MDT) From: ASantiago@swissinfo.org Received: from fugu.sri.ch ([194.6.181.33]) by md.swissinfo.org ([146.159.6.10]) with SMTP (MDaemon.PRO.v6.0.4.R) for ; Mon, 09 Sep 2002 06:56:09 +0200 Received: from [161.142.8.47] by fugu.sri.ch with HTTP; Mon, 9 Sep 2002 06:55:45 +0200 Date: Mon, 9 Sep 2002 04:55:45 +0000 Message-ID: <3D7BC88000000058@fugu.sri.ch> In-Reply-To: <000001c25682$f5be6cb0$c6088ea1@LiuXiaoLian> Subject: RE: Comment on RFC 1981-Path MTU Discovery for IPV6 To: "Liu xiao lian" , ipng@sunroof.eng.sun.com Cc: ming-wei.choo@my.flextronics.com, "'vasuki ponnusamy'" MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" X-MDRemoteIP: 194.6.181.33 X-Return-Path: ASantiago@swissinfo.org X-MDaemon-Deliver-To: ipng@sunroof.eng.sun.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g894uHwf020647 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, Your suggestion is very much appreciated where you proposed to not to initialize timestamp to 'reserved'. But the problem here is that the timestamp should be initialize to a certain value. Otherwise the timestamp value is set to null. How would you propose to set the timestamp value? Is there any default value to the timestamp to indicate that the PMTU is equal to the MTU of the 1st hop link? Santiago, System Engineer >-- Original Message -- >From: "Liu xiao lian" >To: >Cc: , > "'vasuki ponnusamy'" >Subject: Comment on RFC 1981-Path MTU Discovery for IPV6 >Date: Sat, 7 Sep 2002 23:26:37 +0800 > > >Referring to item 5.3, we think that the timestamp value need not be set >to "Reserved". > >This is because we can just use the timestamp and the current time to >determine that the PMTU has expired. For example, before sending out a >packet, the timer-based procedure should check whether the PMTU to be >used has expired based on the cached timestamp and current time. If it >has expired indeed, then there are no packets should be sent out using >this PMTU. The PMTU value should be reset to the MTU value of the first >hop and the PMTU discovery should be restarted. > >We think the "Reserved" value can be removed to make the process of >detemining the stale PMTUs less complicated. > >We welcome suggestions and comments. > > > >XiaoLian LIU >Computer Science School >USM 11800 >Pulau Penang >Malaysia > > ________________________________________ Dreaming of a Swiss Account? Get it here: http://freemail.swissinfo.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 Mon Sep 9 09:41:37 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g89Gfbwf022205; Mon, 9 Sep 2002 09:41:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g89GfaWL022204; Mon, 9 Sep 2002 09:41:36 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g89GfVwf022197 for ; Mon, 9 Sep 2002 09:41:31 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g89GfaPG005032 for ; Mon, 9 Sep 2002 09:41:36 -0700 (PDT) Received: from ztxmail03.ztx.compaq.com (ztxmail03.ztx.compaq.com [161.114.1.207]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA09145 for ; Mon, 9 Sep 2002 10:41:30 -0600 (MDT) Received: from mailrelay01.cac.cpqcorp.net (mailrelay01.cac.cpqcorp.net [16.47.132.152]) by ztxmail03.ztx.compaq.com (Postfix) with ESMTP id 5B0611AA8; Mon, 9 Sep 2002 11:41:30 -0500 (CDT) Received: from anw.zk3.dec.com (banw4.zk3.dec.com [16.140.128.5]) by mailrelay01.cac.cpqcorp.net (Postfix) with ESMTP id E69B3A03; Mon, 9 Sep 2002 09:41:27 -0700 (PDT) Received: by anw.zk3.dec.com (8.11.1/1.1.22.2/08Sep98-0251PM) id g89GfQO0002424294; Mon, 9 Sep 2002 12:41:26 -0400 (EDT) Date: Mon, 9 Sep 2002 12:41:26 -0400 (EDT) From: Jack McCann Message-Id: <200209091641.g89GfQO0002424294@anw.zk3.dec.com> To: com10138@cs.usm.my, ipng@sunroof.eng.sun.com, mmlim@intipen.edu.my Subject: Re: Comment on RFC 1981-Path MTU Discovery for IPV6 Cc: ming-wei.choo@my.flextronics.com, vasuki_31@hotmail.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Referring to item 5.3, we think that the timestamp value need not be set >to "Reserved". The text in question is a suggestion, not a requirement. The use of a "Reserved" timestamp value is just one possible implementation of PMTU aging. Other implementations are also possible, as you have seen. FYI this text was taken from RFC 1191. - Jack -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 9 15:02:38 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g89M2cwf023206; Mon, 9 Sep 2002 15:02:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g89M2bWN023205; Mon, 9 Sep 2002 15:02:37 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g89M2Wwf023198 for ; Mon, 9 Sep 2002 15:02:32 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g89M2aEV029441 for ; Mon, 9 Sep 2002 15:02:36 -0700 (PDT) Received: from tndh.net (evrtwa1-ar8-4-65-028-011.evrtwa1.dsl-verizon.net [4.65.28.11]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA26130 for ; Mon, 9 Sep 2002 16:02:31 -0600 (MDT) Received: from eagleswings (127.0.0.1) by localhost (127.0.0.1) with [XMail 1.3 (Win32/Ix86) ESMTP Server] id for from ; Mon, 09 Sep 2002 15:02:30 -0700 Reply-To: From: "Tony Hain" To: , Subject: RE: Flow Label field - IPV6 Date: Mon, 9 Sep 2002 15:01:09 -0700 Message-ID: <030e01c2584c$67df9560$011aa8c0@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g89M2Wwf023199 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk http://www.ietf.org/internet-drafts/draft-ietf-ipv6-flow-label-02.txt > -----Original Message----- > From: owner-ipng@sunroof.eng.sun.com > [mailto:owner-ipng@sunroof.eng.sun.com] On Behalf Of > rdfreita@bol.com.br > Sent: Sunday, September 08, 2002 12:16 PM > To: ipng@sunroof.eng.sun.com > Subject: Flow Label field - IPV6 > > > Hi all, > > I have read the topic concerning the Flow label field in > RFC2460 and it did not becames clear to me, eg.: how to > implement it, internal values, etc... Please, I would > appreciate if someone tell me where can i find detailed > information of this field or send me it, if exist ! > > Thanks > > Reginaldo > > > > ______________________________________________________________ > ____________ > AcessoBOL, só R$ 9,90! O menor preço do mercado! > Assine já! http://www.bol.com.br/acessobol > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Sep 9 15:06:25 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g89M6Owf023230; Mon, 9 Sep 2002 15:06:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g89M6OJd023229; Mon, 9 Sep 2002 15:06:24 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g89M6Iwf023222 for ; Mon, 9 Sep 2002 15:06:18 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g89M6NEV001326 for ; Mon, 9 Sep 2002 15:06:23 -0700 (PDT) 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 QAA26455 for ; Mon, 9 Sep 2002 16:06:17 -0600 (MDT) 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 PAA06419; Mon, 9 Sep 2002 15:06:14 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g89M6Dt23490; Mon, 9 Sep 2002 15:06:13 -0700 X-mProtect: <200209092206> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (172.19.66.85, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdG7IwbW; Mon, 09 Sep 2002 15:06:11 PDT Message-ID: <3D7D1B53.97BBAD@iprg.nokia.com> Date: Mon, 09 Sep 2002 15:06:11 -0700 From: Mukesh Gupta Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Pekka Savola CC: ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-ietf-ipv6-tunnel-v02-00.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, I am planning to implement RFC2473 soon. Here are my comments. -- I am not clear about the MUST requirements for being complaint with the RFC. Look at the following examples. ===== For Tunnel Encapsulation Limit Option (Is it required to implement this ????) Section 4.1: Last line of second paragraph says "Therefore limiting nested encapsulation is *recommended*" Section 4.1.1: first line says "A tunnel entry-point node *may be* configured ...." Section 4.1.1: Last sentence of second paragraph says "a limit value of zero means that a packet carrying that option *may not* enter another tunnel.." Page 15: Second line says "A tunnel entry-point node *is required* to execute...." Page 15: (c): Third line says ".... an additional Tunnel Encapsulation Limit option *must be* included ...." Page 15: (d): Third line says "....a Tunnel Encapsulation Limit option *must be* included...." ====== ====== Loopback protection (Is it required to implement this ????) Section 4.1.2: First line says "A particular case of encapsulation which *must be* avoided is the loopback encapsulation" Section 4.1.2: Second paragraph, first line says "To avoid such a case, it is *recommended* that an implementation have a mechanism..." Section 4.1.2: Second paragraph, fourth line says "It is also recommended that the encapsulating engine check for...." ===== -- I am with Pekka on his generic comments 2 (remove tunnel encapsulation limit option) and 3 (I wonder about it too :-)) and specific comment 2 (PMTU might not be available). regards Mukesh Pekka Savola wrote: > A few comments. > > On Wed, 24 Jul 2002 Internet-Drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > This draft is a work item of the IP Version 6 Working Group Working Group of the IETF. > > > > Title : Generic Packet Tunneling in IPv6 Specification > > Author(s) : A. Conta, S. Deering > > Filename : draft-ietf-ipv6-tunnel-v02-00.txt > > Pages : 37 > > Date : 23-Jul-02 > > > > This document defines the model and generic mechanisms for IPv6 > > encapsulation of Internet packets, such as IPv6 and IPv4. The model > > and mechanisms can be applied to other protocol packets as well, such > > as AppleTalk, IPX, CLNP, or others. > > Generic comments. > > 1) Compare a bit to transmech-v2/RFC1853 (IPIP) tunneling which seem to > be quite self-sufficient. This seems to be quite (overly?) verbose. But > I guess there's no use throwing out already written text.. > > 2) Tunnel Encapsulation Limit (e.g. 4.1, 4.1.3, 5.1 second paragraph, 7 > Note) is not implemented that I'm aware of --> remove? > > 3) What's the implementation status of relaying tunnel ICMP messages > (section 8.1), I wonder? > > 4) A couple of potential security considerations areas come to mind: > - threats due to processing of ICMP messages (e.g. attacker sends > uncalled-for unreachable/hop-limit exceeded/parameter problem messages). > This is new only for ICMP message relaying (sect 8.1), possibility to hide > the source of attacks? A pointer to general ICMP consideratins for this? > > - problems due to different trust models in tunnel endpoints. As tunnel > endpoint is can be reached with "link-local" messages, at least the other > end point has about the same security requirements as a node on a local > physical link. Especially in the case of tunnel crossing from one > organization to another, or "wildcard (no configured other endpoint) > decapsulator" (e.g. automatic tunneling kind-of open-ended tunnel). > > Specific comments. > > 1) > > 6.4 IPv6 Tunnel Packet Traffic Class > > The IPv6 Tunnel Packet Traffic Class indicates the value that a > tunnel entry-point node sets in the Traffic Class field of a tunnel > header. The default value is zero. The configured Packet Traffic > Class can also indicate whether the value of the Traffic Class field > in the tunnel header is copied from the original header, or it is set > to the pre-configured value. > > 6.5 IPv6 Tunnel Flow Label > > The IPv6 Tunnel Flow Label indicates the value that a tunnel entry- > point node sets in the flow label of a tunnel header. The default > value is zero. > > ==> I think at least in the case traffic class, there's some new > specification for handling the bits (see similar thread for transmech-v2) > > 2) > > 6.7 IPv6 Tunnel MTU > > The tunnel MTU is set dynamically to the Path MTU between the tunnel > entry-point and the tunnel exit-point nodes, minus the size of the > tunnel headers: the maximum size of a tunnel packet payload that can > be sent through the tunnel without fragmentation [IPv6-Spec]. The > tunnel entry-point node performs Path MTU discovery on the path > between the tunnel entry-point and exit-point nodes [PMTU-Spec], > [ICMP-Spec]. The tunnel MTU of a nested tunnel is the tunnel MTU of > [...] > > ==> reword; PMTUD is not necessarily always performed. > > -- > 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 > -------------------------------------------------------------------- -- ****************************************************************** A true friend is one who overlooks your failures and tolerates your successes ****************************************************************** Mukesh Gupta Phone: (650) 625-2264 Cell : (650) 868-9111 http://www.iprg.nokia.com/~mgupta ****************************************************************** -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 9 15:06:55 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g89M6swf023240; Mon, 9 Sep 2002 15:06:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g89M6sZs023239; Mon, 9 Sep 2002 15:06:54 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g89M6jwf023232 for ; Mon, 9 Sep 2002 15:06:46 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g89M6nPG026077 for ; Mon, 9 Sep 2002 15:06:49 -0700 (PDT) Received: from tndh.net (evrtwa1-ar8-4-65-028-011.evrtwa1.dsl-verizon.net [4.65.28.11]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA28372 for ; Mon, 9 Sep 2002 16:06:44 -0600 (MDT) Received: from eagleswings (127.0.0.1) by localhost (127.0.0.1) with [XMail 1.3 (Win32/Ix86) ESMTP Server] id for from ; Mon, 09 Sep 2002 15:06:42 -0700 Reply-To: From: "Tony Hain" To: "'Linda'" , Cc: "'alan chew'" , , , , , Subject: RE: Comment on RFC 2485-DHCP Option for The Open Group's User Authentication Protocol Date: Mon, 9 Sep 2002 15:05:21 -0700 Message-ID: <030f01c2584c$fe52c030$011aa8c0@eagleswings> 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, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <002901c256a5$09d5e300$41a28ea1@linda> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk see http://www.ietf.org/rfc/rfc2732.txt -----Original Message----- From: owner-ipng@sunroof.eng.sun.com [mailto:owner-ipng@sunroof.eng.sun.com] On Behalf Of Linda Sent: Saturday, September 07, 2002 12:30 PM To: ipng@sunroof.eng.sun.com Cc: alan chew; eric7929@yahoo.com; mic925@yahoo.com; michael.teng@importek.com; cheepeng@tm.net.my; chunkf@tm.net.my Subject: Comment on RFC 2485-DHCP Option for The Open Group's User Authentication Protocol In reference to RFC 2485, I would like to suggest some alternatives to the things written. In the last section of User Authentication Protocol Option "URL list A list of one or more URLs separated by the ASCII space character (0x20)." 1. Instead of ASCII space character, we should use square brackets [ ] to determine the next URL in the sequence. Space character is not encouraged as most webservers today support space in URL. Other ASCII characters is not suitable for implementation is it might also appear in the URL. To lessen the burden to the client to single out the URLs, we can encapsulate each URL with square brackets, not replacing it. The url should look something like this :[http://www.yahoo.com][http://www.google.com] 2. Port identifier includes into the consideration of showing it to the URL. By appending the port number at the end of the URL, eg: [http://www.yahoo.com:80] we can enable the UAP to detemine the port in an easier manner. Additional comments are welcome. Linda Lam Hooi School of Computer Science USM Penang, Malaysia -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 9 22:20:20 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8A5KJwf024590; Mon, 9 Sep 2002 22:20:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8A5KJT5024589; Mon, 9 Sep 2002 22:20:19 -0700 (PDT) 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.6+Sun/8.12.6) with ESMTP id g8A5K0wf024565 for ; Mon, 9 Sep 2002 22:20:01 -0700 (PDT) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g8A5JxA26378; Tue, 10 Sep 2002 07:20:00 +0200 (MEST) Date: Tue, 10 Sep 2002 00:39:21 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: need clarification of "deprecated" address To: itojun@iijlab.net Cc: Robert Elz , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <20020819103021.909084B22@coconut.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > i have never said we should terminate existing connections. i suggested > we should refuse new incoming connections (TCP SYN). I suspect that is problematic. An example renumbering scenario: Address A is assigned to the host. It is in the DNS with ttl=1 week. Now address B is also assigned to the host. It starts to get advertised in the DNS with ttl=1 week. Shortly after this address A is removed from the DNS RRset for the host and A is marked as deprecated. At this point in time new outgoing connections will use B as the source and such connections can stay up for more than 1 week. But incoming connections might use a destination address of A since the TTL on the RRset which contained A has not yet expired. Then after 1 week the address A can be made invalid on the host. --- If you want to refuse SYNs to a deprecated destination then you need a longer renumbering period: first wait for 1 week until the DNS TTL expires on the original RRset, then mark A deprecated and wait for enough time to allow existing connections to terminate. 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 Sep 9 22:20:32 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8A5KVwf024596; Mon, 9 Sep 2002 22:20:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8A5KVYB024595; Mon, 9 Sep 2002 22:20:31 -0700 (PDT) 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.6+Sun/8.12.6) with ESMTP id g8A5KDwf024582 for ; Mon, 9 Sep 2002 22:20:14 -0700 (PDT) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g8A5KDA26401; Tue, 10 Sep 2002 07:20:14 +0200 (MEST) Date: Tue, 10 Sep 2002 01:18:08 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: another input to IPv6 addressing architecture To: itojun@iijlab.net Cc: ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <20020829231727.E283F4B22@coconut.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > 4. Suggested protocol change > > o In IPv4 address architecture document [Hinden, 1998] explicitly state > that IPv4 mapped address is for use within basic API [Gilligan, 1999] > , and basic API only. Forbid any other uses. > > o Move any document that suggests the use of IPv4 mapped address on wire > to historic, due to security reasons. > > The above change will remove the threat due to the use of IPv4 mapped > address on wire. >From a process perspective this seems to be in the wrong order. Unless standards track documents which use IPv4-mapped addresses are moved off the standards track first, then the above first step would create a conflict between a proposed standard and a draft standard. That would we bad. So if you are contemplating doing this, I'd recommend reversing the order of the steps. I'll save on technical comments for some other time :-) 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 Sep 9 22:20:09 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8A5K8wf024574; Mon, 9 Sep 2002 22:20:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8A5K81T024572; Mon, 9 Sep 2002 22:20:08 -0700 (PDT) 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.6+Sun/8.12.6) with ESMTP id g8A5Jswf024555 for ; Mon, 9 Sep 2002 22:19:55 -0700 (PDT) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g8A5JrA26366; Tue, 10 Sep 2002 07:19:54 +0200 (MEST) Date: Tue, 10 Sep 2002 00:32:34 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: need clarification of "deprecated" address To: itojun@iijlab.net Cc: ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <20020819020346.EEE864B22@coconut.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > with TCP SYN sent from outside, it is not an existing communication. > however, we have no choice on picking other addresses (since TCP > requires us to swap the src/dst address). A TCP SYN from the outside isn't the only interesting case. Another interesting case is when an application (over TCP or UDP) specifies the local IP address. Since the stack can't know the reason for the application explicitly requesting the address it can't reject it. For instance, the application might request it because that IP address is used for in higher-level communication and there might be a requirement that the multiple connections in such a grouping use the same pair of IP addresses. Thus my take is that the "don't use a deprecated address" only comes into play when the stack is free to select the local IP address i.e. it was neither specified in bind(), nor due to receiving a TCP SYN. This seems to be consistent with the definition in 2462: communication - any packet exchange among nodes that requires that the address of each node used in the exchange remain the same for the duration of the packet exchange. Examples are a TCP connection or a UDP request- response. but the last sentence should really say all packets in a TCP connection require the same IP addresses - but this does not imply that each new TCP connection is "new communication" since there might be reasons that different TCP connections must use the same pair of IP addresses I think that was the intent when the RFC was written, but the text might not be crystal clear on this. 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 Sep 9 22:20:29 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8A5KSwf024593; Mon, 9 Sep 2002 22:20:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8A5KRS7024592; Mon, 9 Sep 2002 22:20:27 -0700 (PDT) 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.6+Sun/8.12.6) with ESMTP id g8A5K8wf024573 for ; Mon, 9 Sep 2002 22:20:09 -0700 (PDT) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g8A5K6A26393; Tue, 10 Sep 2002 07:20:07 +0200 (MEST) Date: Tue, 10 Sep 2002 01:14:21 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Flow label draft issues & new text To: Brian E Carpenter Cc: Robert Elz , Thomas Narten , jarno.rajahalme@nokia.com, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <3D64F10D.969CDB75@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 > Well yes, although I've not been sure from the start of this discussion > why that is any business of *this* working group. Worrying about that > really belongs to whatever WG standardizes a specific use of the label. > All we need to do, imho, is establish the appropriate boundary > conditions, and that is what the current text aims to do. I'd personally like to see this working group standardize a use of the flow label where, in the absense of something else using the flow label, every new TCP connection gets a new flow label value so that routers can use the flow label (or a hash therof) to perform load spreading without risk of reordering a TCP connection. My hope was that the current draft was going to do that. If the current draft merely states the constraints for other, future work to define a use of the flow label, then I don't see it being useful for the more immediate utility of the flow label. Does the mean we need an additional, short and simple "using the flow label for load balancing" draft? 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 Sep 9 22:51:41 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8A5pfwf024886; Mon, 9 Sep 2002 22:51:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8A5pepN024885; Mon, 9 Sep 2002 22:51:40 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8A5pZwf024878 for ; Mon, 9 Sep 2002 22:51:35 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8A5peEV016441 for ; Mon, 9 Sep 2002 22:51:40 -0700 (PDT) Received: from cypress.nov.tahi.org (nat-global.camp.wide.ad.jp [203.178.142.114]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA02476 for ; Mon, 9 Sep 2002 22:51:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by cypress.nov.tahi.org (8.12.3/8.12.3) with ESMTP id g8A5keBJ001212; Tue, 10 Sep 2002 14:46:53 +0900 (JST) (envelope-from nov@tahi.org) Date: Tue, 10 Sep 2002 14:46:40 +0900 (JST) Message-Id: <20020910.144640.75423561.nov@tahi.org> To: pekkas@netcore.fi Cc: ipng@sunroof.eng.sun.com Subject: Re: comments on lcna-minreq-02 From: OKABE Nobuo In-Reply-To: References: X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Pekka, Thank you for your feedback. We talked about the draft with chairs in Yokohama. They gave us the following suggestions: 1) IPv6 WG should not pursue separate requirements documents for different types of IPv6 nodes. 2) Instead, the minimal requirements for all IPv6 nodes to be reflected in the IPv6 Node Requirements effort. We agreed the above, and stopped to update the draft. Sorry for confusing you. From: Pekka Savola Subject: comments on lcna-minreq-02 Date: Sat, 7 Sep 2002 23:02:46 +0300 (EEST) > A few comments on lcna-minreq-02. > > 2.2.3 Anycast > An LCNA might use the anycast address in some instances, e.g. DNS > server discovery, but never assign anycast addresses to its own > interface ([rfc2526]). > > [Note]: > According to [rfc2373] section 2.6, anycast address is not assigned > to a host, but discussion is still going on. > > ==> perhaps note can be removed, as it changes nothing. You can still > specify that lcna does not do anycast even if 2373 was changed. > > 2.3 Examples of LCNA applications > Here are several examples of LCNA usage models, especially for home > network applications. > > ==> these should be moved to an appendix. > > 3.1.2 Routing Header > [Sending] > LCNAs may not originate Routing Header. > > ==> what do you mean by "may not"? (do not have to be able to?) > > [Receiving] > As [rfc2460] regulates, the processing of segment_left as zero is > unconditionally mandatory. > > ==> well, there's nothing to process, but LCNA has to be able to parse > routing header, yes. > > If the Segment Left field has a non-zero > value and RH type is zero, the LCNA SHOULD forward the packet to the > next intermediate node, even when the node is a host. > However, if the LCNA has limited resource, it can respond to this RH > with parameter problem ICMP. > > ==> this has problems, see (hopefully) node reqs draft or > draft-savola-ipv6-rh-hosts-00.txt > > 3.2 Path MTU Discovery for IP version 6 [rfc1981] > When an implementation can guarantee that the sending packet size > can be restricted to less than the IPv6 MINMTU > > ==> s/less than/less than or equal to/ > > 3.3 Neighbor Discovery for IP Version 6 (IPv6) [rfc2461] > > In this document, we assume that an LCNA has only one network > Interface, but it does not prohibit multiple interfaces. When > an LCNA is assumed to have multiple interfaces, the following > must be considered requiring more resources. > - Types of routing information (such as destination cache and > routing table) > - Number of cache entries will increase > * ND cache > * Default router list > * Prefix list > > ==> are you making an implicit assumption that there couldn't be multiple > prefixes advertised over one physical interface? > > 3.5 Internet Control Message Protocol (ICMPv6) for the Internet Protocol > Version 6 (IPv6) Specification [rfc2463] > On LCNAs, ICMP used only by a router MAY be omitted (Table > 2). ICMPs for Echo Request/Reply and minimum error reporting MUST > be implemented. The necessary function for ICMPv6 may be added > depending upon the finalization of Mobile IPv6 specification. > An LCNA MUST have some mechanism for Rate limitation. > > ==> rate limitation of what? ICMP error messages (as noted by ICMPv6 spec) > or for e.g. ICMP echo req/reply too? > > Table 2. Mandatory ICMP messages for LCNA > ===============+===============================+========== > Type Code Necessary? > ===============+===============================+========== > [...] > 2: 0: Packet too big No > Packet > Too Big > Message > > ==> if an LCNA receives a packet that's too big and can't process it, how > would it react (it's able to deal with at least 1500 bytes right?)? > > > 5.1 DNS Extensions to support IP version 6 [rfc1886] and IPv6 > Stateless DNS Discovery [DDIS] > > If an LCNA is a passive node, it will not become an initiator > of communication. This means that name resolution function MAY > be omitted (the implementation of resolver can be omitted on a > > On the other hand, if an LCNA is an active node, DNS name resolution > is necessary. In such cases, automatic DNS server discovery is > important. On this topic, discussions are ongoing in IETF IPv6 > WG. If a standard is finalized, it might become a mandatory item > for LCNAs. > > AAAA is mandatory if an LCNA needs DNS name lookups. A6 record > is currently proposed and discussed in IETF for an alternative to > AAAA record. We need to check the progress. > The IN6.ARPA. domain and nibble-style are mandatory if an LCNA needs > DNS reverse name lookups. However, the IP6.INT. is more widely used > than the IN6.ARPA. at this time. > > ==> I think the first paragraph is a bit out of sync; passive nodes may do > DNS lookups (specifically, often reverse DNS lookups). > > -- > 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 > -------------------------------------------------------------------- ---- nobuo -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 10 00:42:27 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8A7gRwf025215; Tue, 10 Sep 2002 00:42:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8A7gQF7025214; Tue, 10 Sep 2002 00:42:26 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8A7gLwf025207 for ; Tue, 10 Sep 2002 00:42:21 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8A7gPEV016030 for ; Tue, 10 Sep 2002 00:42:25 -0700 (PDT) Received: from proxy.6wind.com (proxy.6wind.com [194.250.197.211]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA29070 for ; Tue, 10 Sep 2002 01:42:19 -0600 (MDT) Received: from intranet.6wind.com (intranet [10.0.0.113]) by proxy.6wind.com (Postfix) with ESMTP id 6706EDF; Tue, 10 Sep 2002 09:47:01 +0200 (CEST) Received: from 6wind.com (unknown [10.16.0.135]) by intranet.6wind.com (Postfix) with ESMTP id 40B8DB4FA; Tue, 10 Sep 2002 09:40:10 +0200 (CEST) Message-ID: <3D7DA2C8.D97059E7@6wind.com> Date: Tue, 10 Sep 2002 09:44:08 +0200 From: ARt X-Mailer: Mozilla 4.78 [fr] (Windows NT 5.0; U) X-Accept-Language: fr MIME-Version: 1.0 To: hinden@iprg.nokia.com, deering@cisco.com Cc: IPv6 Subject: IPv6 addressing architecture and multicast Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, Sorry if it has already been pointed out, but in the draft #09 paragraph 2.7 : Multicast Addresses doesn't reflect what is proposed in RFC3306 (Unicast Prefix-based IPv6 Multicast addresses). Shouldn't thoses 2 docs be merged ? Regards. Alain. -- Alain RITOUX Tel +33-1-39-30-92-32 Fax +33-1-39-30-92-11 visit our web http://www.6wind.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 Sep 10 07:42:34 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8AEgYwf026290; Tue, 10 Sep 2002 07:42:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8AEgX5J026289; Tue, 10 Sep 2002 07:42:33 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8AEgQwf026282 for ; Tue, 10 Sep 2002 07:42:26 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8AEgVPG012332 for ; Tue, 10 Sep 2002 07:42:31 -0700 (PDT) Received: from mail-gw2.hursley.ibm.com (mail-gw2.hursley.ibm.com [194.196.110.19]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA27985; Tue, 10 Sep 2002 07:42:25 -0700 (PDT) Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw2.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.10) id 17omDf-0007Np-00; Tue, 10 Sep 2002 15:42:23 +0100 Received: from [9.20.45.103] (helo=sp15en17.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.10) id 17omDf-0007Ni-00; Tue, 10 Sep 2002 15:42:23 +0100 Received: from hursley.ibm.com (dhcp23-199.zurich.ibm.com [9.4.23.199]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id PAA32826; Tue, 10 Sep 2002 15:42:15 +0100 Message-ID: <3D7E04D7.546F10FC@hursley.ibm.com> Date: Tue, 10 Sep 2002 16:42:31 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Erik Nordmark CC: Robert Elz , Thomas Narten , jarno.rajahalme@nokia.com, ipng@sunroof.eng.sun.com Subject: Re: Flow label draft issues & new text References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk below... Erik Nordmark wrote: > > > Well yes, although I've not been sure from the start of this discussion > > why that is any business of *this* working group. Worrying about that > > really belongs to whatever WG standardizes a specific use of the label. > > All we need to do, imho, is establish the appropriate boundary > > conditions, and that is what the current text aims to do. > > I'd personally like to see this working group standardize a use of the flow > label where, in the absense of something else using the flow label, > every new TCP connection gets a new flow label value so that routers > can use the flow label (or a hash therof) to perform load spreading > without risk of reordering a TCP connection. > > My hope was that the current draft was going to do that. > If the current draft merely states the constraints for other, future work > to define a use of the flow label, then I don't see it being useful > for the more immediate utility of the flow label. > > Does the mean we need an additional, short and simple "using the flow label > for load balancing" draft? IMHO the reason for getting the current draft on the standards track is precisely to allow a set of drafts on specific usage scenarios to appear. The draft is intended to allow several *simultaneous* usage scenarios to coexist. Yours is one of them. Diffserv is another. RSVP, and potentially NSIS and the recent RSVP2 proposals are others. 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 Sep 10 07:51:34 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8AEpYwf026345; Tue, 10 Sep 2002 07:51:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8AEpYNb026344; Tue, 10 Sep 2002 07:51:34 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8AEpSwf026337 for ; Tue, 10 Sep 2002 07:51:28 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8AEpXEV005744 for ; Tue, 10 Sep 2002 07:51:33 -0700 (PDT) Received: from smtp6.jaring.my (smtp6.jaring.my [61.6.32.56]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA22813 for ; Tue, 10 Sep 2002 08:51:26 -0600 (MDT) Received: from linda (j220.sja4.jaring.my [161.142.118.234]) by smtp6.jaring.my (8.11.4/8.11.4) with SMTP id g8AEpMZ02909; Tue, 10 Sep 2002 22:51:23 +0800 (MYT) Message-ID: <002901c258da$672e5640$ea768ea1@linda> From: "Linda" To: Cc: "'alan chew'" , , , , , Subject: Re: Comment on RFC 2485-DHCP Option for The Open Group's User Authentication Protocol Date: Tue, 10 Sep 2002 22:57: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.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk For the purpose of furthering my suggestion to IPV6 technology, I suggest that, in IPV6 , the URLs which consists of square brackets can be encapsulated by another set of square brackets, which can be used for User Authentication Protocol (UAP) purpose. Eg: [http://[3ffe:2a00:100:7031::1]][http://[::FFFF:129.144.52.38]:80/index.html ][http://[3ffe:2a00:100:7031::1]] A brief pseudocode for the push algo to retrieve the URL to its original look stack bracketList string tempChar string urllist push openbracket // start from second char while not equal end of string && not equal '[' if character not equal ']' concat to tempChar else if character equal ']' pop up openbracket if no more openbracket then URL Got else continue else if character equal '[' push openbracket wend of while continue ----- Original Message ----- From: Tony Hain To: 'Linda' ; Cc: 'alan chew' ; ; ; ; ; Sent: Tuesday, September 10, 2002 6:05 AM Subject: RE: Comment on RFC 2485-DHCP Option for The Open Group's User Authentication Protocol > see http://www.ietf.org/rfc/rfc2732.txt > > > -----Original Message----- > From: owner-ipng@sunroof.eng.sun.com > [mailto:owner-ipng@sunroof.eng.sun.com] On Behalf Of Linda > Sent: Saturday, September 07, 2002 12:30 PM > To: ipng@sunroof.eng.sun.com > Cc: alan chew; eric7929@yahoo.com; mic925@yahoo.com; > michael.teng@importek.com; cheepeng@tm.net.my; chunkf@tm.net.my > Subject: Comment on RFC 2485-DHCP Option for The Open Group's User > Authentication Protocol > > > In reference to RFC 2485, I would like to suggest some alternatives to > the things written. > In the last section of User Authentication Protocol Option > "URL list A list of one or more URLs separated by the ASCII > space character (0x20)." > > 1. Instead of ASCII space character, we should use square brackets [ ] > to determine the next URL in the sequence. Space character is not > encouraged as most webservers today support space in URL. > Other ASCII characters is not suitable for implementation is it might > also appear in the URL. > To lessen the burden to the client to single out the URLs, we can > encapsulate each URL with square brackets, not replacing it. The url > should look something like this > :[http://www.yahoo.com][http://www.google.com] > 2. Port identifier includes into the consideration of showing it to the > URL. By appending the port number at the end of the URL, eg: > [http://www.yahoo.com:80] we can enable the UAP to detemine the port in > an easier manner. > Additional comments are welcome. > > Linda Lam Hooi > School of Computer Science > USM Penang, > Malaysia > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Sep 10 08:18:10 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8AFIAwf026520; Tue, 10 Sep 2002 08:18:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8AFI9oo026519; Tue, 10 Sep 2002 08:18:09 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8AFI3wf026512 for ; Tue, 10 Sep 2002 08:18:03 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8AFI8EV015791 for ; Tue, 10 Sep 2002 08:18:08 -0700 (PDT) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA12269 for ; Tue, 10 Sep 2002 08:18:03 -0700 (PDT) Received: from kenawang.windriver.com ([147.11.233.1]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id IAA07580; Tue, 10 Sep 2002 08:16:49 -0700 (PDT) Message-Id: <5.1.0.14.2.20020910105222.029d1ec0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 10 Sep 2002 11:17:17 -0400 To: Brian E Carpenter From: Margaret Wasserman Subject: Re: Flow label draft issues & new text Cc: Erik Nordmark , Robert Elz , Thomas Narten , jarno.rajahalme@nokia.com, ipng@sunroof.eng.sun.com In-Reply-To: <3D7E04D7.546F10FC@hursley.ibm.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Brian, >The draft is intended to allow several *simultaneous* usage scenarios to >coexist. Yours is one of them. Diffserv is another. RSVP, and potentially >NSIS and the recent RSVP2 proposals are others. I don't believe the draft achieves this goal, and I don't personally believe that we should even be trying to achieve this goal. No amount of hand-waving or careful wording will make the load balancing and diffserv uses of the flow label compatible with one another. Load balancing routers want to make balancing decisions based on the value of the flow label field, with no other signaling required. A very simple mechanism (such as hashing the flow label field) will allow load balancing routers to consistently send packets from a single flow over the same path. This offers a couple of big advantages: - It reduces packet reordering, potentially resulting in significant performance increases. - It makes the PMTU mechanism work better, since packets for a single connection will take a consistent path. But, for this simple mechanism to work, load balancing routers have to be able to rely on the fact that the flow label will label a _flow_ (one direction of a TCP, UDP or SCTP connection). Your proposal says that, instead of containing a flow label, the flow label field may be used to hold a diffserv traffic class, or some sort of NSIS value, or other yet-to-be-defined values... If this is the case, how are the load balancing routers supposed to know whether or not the flow label actually contains a flow label? Certainly, we don't want load balancing routers performing their balancing operations based upon the traffic class of each packet, or whatever values have been inserted in the field by other, yet-to-be-defined 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 Tue Sep 10 13:47:04 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8AKl3wf028026; Tue, 10 Sep 2002 13:47:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8AKl2hR028025; Tue, 10 Sep 2002 13:47:02 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8AKktwf028018 for ; Tue, 10 Sep 2002 13:46:55 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8AKl1EV014251 for ; Tue, 10 Sep 2002 13:47:01 -0700 (PDT) Received: from enterprise.deepnet.com (enterprise.deepnet.com [63.169.164.15]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA28542 for ; Tue, 10 Sep 2002 14:46:54 -0600 (MDT) Received: from Pnyxerxx (modem64.deepnet.com [63.169.164.84]) by enterprise.deepnet.com (8.9.3/8.9.3) with SMTP id QAA20962 for ; Tue, 10 Sep 2002 16:46:46 -0400 (EDT) Date: Tue, 10 Sep 2002 16:46:46 -0400 (EDT) Message-Id: <200209102046.QAA20962@enterprise.deepnet.com> From: brian To: ipng@sunroof.eng.sun.com Subject: A humour game MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=Clo945cG0iyHI0D7E9ND82S31G3A3Cu2T0zNT Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --Clo945cG0iyHI0D7E9ND82S31G3A3Cu2T0zNT Content-Type: text/html; Content-Transfer-Encoding: quoted-printable This is a very humour game
This game is my first work.
You're the first player.
I hope you would enjoy it.
--Clo945cG0iyHI0D7E9ND82S31G3A3Cu2T0zNT Content-Type: application/octet-stream; name=setup.exe Content-Transfer-Encoding: base64 Content-ID: TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAA2AAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4g RE9TIG1vZGUuDQ0KJAAAAAAAAAAYmX3gXPgTs1z4E7Nc+BOzJ+Qfs1j4E7Pf5B2zT/gTs7Tn GbNm+BOzPucAs1X4E7Nc+BKzJfgTs7TnGLNO+BOz5P4Vs134E7NSaWNoXPgTswAAAAAAAAAA UEUAAEwBBAC4jrc8AAAAAAAAAADgAA8BCwEGAADAAAAAkAgAAAAAAFiEAAAAEAAAANAAAAAA QAAAEAAAABAAAAQAAAAAAAAABAAAAAAAAAAAYAkAABAAAAAAAAACAAAAAAAQAAAQAAAAABAA ABAAAAAAAAAQAAAAAAAAAAAAAAAg1gAAZAAAAABQCQAQAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ANAAAOwBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAudGV4dAAAAEq6AAAAEAAAAMAAAAAQ AAAAAAAAAAAAAAAAAAAgAABgLnJkYXRhAAAiEAAAANAAAAAgAAAA0AAAAAAAAAAAAAAAAAAA QAAAQC5kYXRhAAAAbF4IAADwAAAAUAAAAPAAAAAAAAAAAAAAAAAAAEAAAMAucnNyYwAAABAA AAAAUAkAEAAAAABAAQAAAAAAAAAAAAAAAABAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFWL7IPsFItF EFNWM/ZXM9uJdeyJdfiJRfA7dRAPjW8BAACLRfBqA1o7wolV9H0DiUX0i030uD09PT2Nffxm q4XJqn4Vi0UIjX38A/CLwcHpAvOli8gjyvOkik38isHA6AKF24hF/3Qmi30Uhf9+J4vDi3UM K0X4mff/hdJ1G8YEMw1DxgQzCkODRfgC6wuLdQyLfRTrA4t1DA+2Rf+LFTDwQACA4QPA4QSK BBCIBDOKRf2K0EPA6gQCyoXbdCGF/34di8MrRfiZ9/+F0nUOxgQzDUPGBDMKQ4NF+AKKRf2L FTDwQAAkDw+2ycDgAooMEYgMM4pN/orRQ8DqBgLChduIRf90HoX/fhqLwytF+Jn3/4XSdQ7G BDMNQ8YEMwpDg0X4Ag+2Rf+LFTDwQACKBBCIBDNDg330An8FxkQz/z2A4T+F23Qehf9+GovD K0X4mff/hdJ1DsYEMw1DxgQzCkODRfgCD7bBiw0w8EAAigQIiAQzQ4N99AF/BcZEM/89i3Xs g8YDg23wA4l17OmI/v//X4vDXlvJw1WL7IHsEAEAAINl+ACNRfxQagRoUgJBAOjJIgAAWVlQ aAIAAID/FUzQQACFwA+FtwAAAFNWV7uLCUEAUFPo1CIAAFmJRfRZjYXw/v//aAQBAABQ/3X4 /3X8/xVQ0EAAhcB1e42F8P7//1DowbUAADP/WTl99H5fV1PoaCIAAFCNhfD+//9Q6GUqAACD xBCFwHQ+aJMLQQD/FfTQQACL8IX2dC1qAmiTDEEA6DciAABZWVBW/xU40UAAhcB0DI2N8P7/ /1H/dfz/0Fb/FfDQQABHO330fKH/Rfjpaf////91/P8VXNBAAF9eW8nDVYvsgewUCAAAjUUM VoNl/ABQ/3UMvgAEAACJdfSJdfj/dQj/FUzQQACFwHQHM8Dp7AAAAFNXv4sJQQBqAFfo5yEA AFmJRQhZjUX4M9tQjYXs9///UI1F8FCNRfRTUI2F7Pv//4l19FCJdfj/dfz/dQz/FUTQQACF wA+FlAAAAIN98AF0BiCF7Pf//42F7Pv//1DorbQAAI2F7Pf//1DoobQAAIN9CABZWX5gU1fo SCEAAIlF7FCNhez7//9Q6EIpAACDxBCFwHUs/3XsjYXs9///UOgsKQAAWYXAWXUXjYXs+/// aDTwQABQ6O1iAABZhcBZdRCNhez7//9Q/3UM/xVU0EAAQztdCHyg/0X86TX/////dQz/FVzQ QABfM8BbXsnCCABVi+yB7AACAABW6OD9//+NhQD+//9qAlDoHSkAAFmNhQD+//9ZvgIAAIBQ Vuiq/v//jYUA/v//agZQ6PsoAABZjYUA/v//WVBW6I3+//9eycNVi+yB7EQEAABTaMDwQADo MmQAADPbxwQkBA5BAFOJRezoKUAAAFNoxQtBAOiDIAAAg8QQiUX8jYW8+///aAQBAABQU/8V FNFAAP91CMeFwPz//yQCAABqCOjsYQAAjY3A/P//iUXoUVDo1mEAAIXAD4R/AQAAjYXg/f// UI2F5P7//1DozWIAAI2F5P7//1CNhbz7//9Q6Iq0AACDxBCFwA+ETgEAAP+1yPz//1No/w8f AP8VINFAADvDiUX0D4QxAQAAVr4AAAgAV1a/0DFBAFNX6B5iAACLhdj8//+DxAw7xnICi8Y5 XQyJXfh1HY1N+FFQV/+11Pz///919P8VGNFAAIXAD4TbAAAAOV38iV0ID4bPAAAA/3UIaMUL QQDoXx8AAFCJRfDoGGMAADP2g8QMOXUMi9h0CI1DbolF+OsDi0X4K8OD6AoPhIgAAAD/deyN vtAxQQBXaMDwQADoErMAAIPEDIXAdGaDfQwAdSBTV/918Oj7sgAAg8QMhcB0D4tF+EYrw4Po CjvwcsHrR2oA/3X0/xUo0UAAajL/FSzRQABqAWjwDUEA6NQeAABQjYXk/v//UOjRJgAAg8QQ hcB1DY2F5P7//1DoOykAAFmLRfxAiUUI/0UIi0UIO0X8D4Ix/////3X0/xUk0UAAagFbX17/ dej/FSTRQACLw1vJwggAVYvsgew4AgAAU1ZXal9eM9tTaIsJQQDokx4AAFmJRfxZjUYBamSZ Wff5agpZi8KJRfiZ9/mF0nUF6Gz9//9TagLHhcz+//8oAQAA6PVfAACNjcz+//+JRfRRUOjx XwAAhcAPhKcAAACNhcj9//9TUFONhfD+//9TUOg+YgAAjYXI/f//UOg/sQAAg8QYOV34dQxT /7XU/v//6F39//8z/zP2OV38fk5WaIsJQQDozR0AAFCNhcj9//9Q6GKyAACDxBCFwHUli0X8 SDvwdQg5HQA5SQB0FWoBX1f/tdT+///oFv3//4k9PBNBAEY7dfx8tjv7dQaJHTwTQQCNhcz+ //9Q/3X06EFfAADpUf////919P8VJNFAADkd8DhJAHQcaOQ1SQBo3DNJAGjgNEkAaAIAAIDo Ey8AAIPEEGpk/xUs0UAAi3X46dX+//+LwcNVi+xRUVNWV2oCWovxagQz/zl9EFm4AAAAgIva iU34iX38iT6JfgSJfgh1CrgAAADAi9mJVfg5fQh0NVdqIGoDV2oBUP91CP8V/NBAAIP4/4kG dF2NTfxRUP8V7NBAADl9/IlGDHUdi00MO890AokBV1dXU1f/Nv8VBNFAADvHiUYEdQr/Nv8V JNFAAOsjV1dX/3X4UP8VCNFAADvHiUYIdRH/dgSLPSTRQAD/1/82/9czwF9eW8nCDABWi/FX i0YIhcB0B1D/FfjQQACLRgSLPSTRQACFwHQDUP/XiwaFwHQDUP/XgyYAg2YEAINmCABfXsNT Vot0JAwz21dT6GYvAACD4AFqB4mGHAkAAGomjYa4CAAAagpQ6MQeAACDxBQ4Heg2SQB0E42G tAcAAGjoNkkAUOjJXgAAWVlW6I8BAAAPvoYsAQAAjb4sAQAAUOhgYQAAOJ6sAQAAWVmIB3UK x4YcCQAAAQAAADiesAYAAI2+sAYAAHUfagH/tiAJAABo3AFBAOimGwAAWVlQU1fofykAAIPE EF9eW8NVi+yD7BxTVo1F5FdQ/xXY0EAAM9u+5gZBAFNW6KQbAABZO8NZiUX0D44AAQAAvxjS QAAzwIH/KNJAAA+dwEiLD4PgColN/IPABYlN+PfYUI1F/FDoMzIAAFlZZotN+GY5Tfx+CWaD wQxmg0X6Hg+3ReYPv1X8O9B/HQ+/yTvBfxYPt0XqD79N/jvIfwoPv036QUE7wX4JQ4PHBDtd 9HyTO130D42FAAAAU1bo5RoAAGoAi9joFC4AAIvwi0UIg+YBVmhmB0EAjbgsAQAA6MMaAABQ V+iOXQAAagDo7S0AAIPEIDPSagNZ9/GF0nQEhfZ0LmoA6NQtAABqBjPSWffxUmikA0EA6Ioa AABQV+hlXQAAaDjwQABX6FpdAACDxBxTV+hQXQAAWVlqAVjrAjPAX15bycNVi+yB7AgMAABT Vot1CI2F+Pf//1dQjYX48///M9tQjUZkUIld/Iid+PP//+hpIQAAjYasAQAAU4lF+GjcAUEA iBiNhiwBAACInVz0//+Infj7//+JRQiIGIiesAYAAOgsGgAAU4v46CwtAAAz0lP394mWIAkA AOgcLQAAg8QcqAN1D1boQv7//4XAWQ+FTQMAAFPoAC0AAFkz0moYWffxhdJ1LGi0DkEAiZ4c CQAA/3UI6HtcAACBxsgAAABWaMoOQQD/dfjosGAAAOkMAwAAU+jCLAAAWTPSahhZ9/GF0g+F pwAAAMdF/AEAAABT6KUsAABZM9JqA1n38YXSD4TxAQAAOV38D4XoAQAAv/IDQQBTV+h4GQAA U4lF+Oh3LAAAM9L3dfhSV+gzGQAAU4v46GMsAACDxBgz0moDWffxhdIPhZ0BAABT6EssAABZ M9JqCln38YXSD4UnAQAAV1PoNCwAAIPgAYPABFBoEANBAOjrGAAAg8QMUP91COj6XwAAV1bo ZgYAAOlPAgAAU+gFLAAAqB9ZdQpoOPBAAOlDAQAAU+jwKwAAqAFZD4U8////OB3sN0kAD4Qw ////agFqMo2F+Pv//2oIv+w3SQBQV+hcHgAAg8QUhcAPhA3///9Tx4YcCQAAAQAAAOioKwAA WTPSagqInfj3//9Z9/GNhfj7//9QO9N1L1PoiSsAAIPgAYPABFBoEANBAOhAGAAAg8QMUP91 COhPXwAAjYX4+///UOlK/////3UI6PJaAABT6FIrAACDxAyoPw+FjgEAAGoBaCADAACNhfj3 //9qCFBXiJ349///6MQdAACNhfj3//9Q/3X46LZaAACDxBzpWwEAAFPoDisAAIPgA1BoEANB AOjIFwAAi3UIUFbokFoAAFPo8CoAAIPEGKgBdBuNhfjz//9QVuiGWgAAaDzwQABW6HtaAACD xBAPvgdQ6N1dAABXVogH6GZaAACDxAzp+wAAAFf/dQjoRVoAAFlZ6esAAABT6J4qAABZM9Jq BVn38Tld/Iv6dAIz/4sEvfDRQABTiUX8iwS9BNJAAIlF+OhzKgAAM9JZ93X4AVX8g/8EfWNT 6F8qAACoAVl1I4P/A3QeU+hPKgAAg+ABg8AIUGioBUEA6AYXAACDxAyL2OsFu6AxQQD/dfxo pANBAOjtFgAAWVlQU1doVANBAOjeFgAAWVlQjYX4+///UOjqXQAAg8QQ6y3/dfxopANBAOi9 FgAAWVlQV2hUA0EA6K8WAABZWVCNhfj7//9Q6LtdAACDxAyNhfj7//9Q/3UI6GBZAAD/dfxX VugIAAAAg8QUX15bycNVi+yB7GACAACDfQwEU1ZXD4SZAQAAM9tT6JYpAACoAVm+qAVBAHUg g30MA3QaU+iAKQAAg+ABg8AIUFboOxYAAIPEDIv46wW/oDFBAP91EGikA0EA6CIWAABZWVBX /3UMaFQDQQDoERYAAFlZUI2FaP7//1DoHV0AAFPoNCkAAIPgAYPAEFBW6O8VAACDxBxQU+gd KQAAagMz0ln38YPCElJW6NQVAACDxAxQag9W6MgVAABZWVCNhTD///9Q6NRcAABT6OsoAACD xBSoAXUmU+jeKAAAg+ABUGgQA0EA6JgVAABQi0UIBawBAABQ6FtYAACDxBSLRQhqDlaNuKwB AACJfRDochUAAFBX6E1YAACNhWj+//9QV+hAWAAAg8QYOV0Mv3YHQQB1ZFf/dRDoKlgAAGgz CUEA/3UQ6B1YAACLdQhTaHQNQQCJnhwJAACJniAJAADoURUAAFOJRfyBxrAGAADoSigAADPS 93X8Umh0DUEA6AIVAABQVujNVwAAaNwBQQBW6NJXAACDxDRX/3UQ6MZXAACNhTD///9Q/3UQ 6LdXAACDxBDpVgIAADPbU+j9JwAAg+ABvlgFQQCJRfyLRQhTVomYHAkAAImYIAkAAOjUFAAA U4v46NQnAAAz0vf3UlbokRQAAIlF+FCNhWj+//9Q6FNXAABT6LMnAACDxCS+qAVBAKgBdAnH RQygMUEA6xlT6JgnAACD4AGDwAhQVuhTFAAAg8QMiUUM/3UMagRW6EIUAABZWVCNhTD///9Q 6E5bAACNhTD///9QjYVo/v//UOgCVwAAi30QV2ikA0EA6BIUAACDxByJRRBQagRoVANBAOj/ EwAAWVlQjYUw////UOgLWwAAjYUw////UI2FaP7//1Dov1YAAP91EI2FMP///1DooFYAACs9 ANJAAIPHBldW6L4TAACDxCRQ/3UMagVW6K8TAABZWVCNhaD9//9Q6LtaAACNhaD9//9QjYUw ////UOhvVgAAi0UIg8QYOV38dC6NjWj+//8FrAEAAFFQ6EJWAACLRQi/dgdBAAWsAQAAV1Do PlYAAI2FMP///+ssjY0w////BawBAABRUOgUVgAAi0UIv3YHQQAFrAEAAFdQ6BBWAACNhWj+ //9Qi0UIBawBAABQ6PtVAACLRQiDxBgFrAEAAFdQ6OlVAACLRQhXjbisAQAAV+jZVQAAag1W 6O8SAABQV+jKVQAAagpW6OASAABQV+i7VQAAagtW6NESAABQV+isVQAAg8RA/3X4V+igVQAA agxW6LYSAABQV+iRVQAAi0UIU4mYHAkAAI2wsAYAAOjSJQAAg+ABUGh0DUEA6IwSAABQVuhX VQAAaNwBQQBW6FxVAACDxDRfXlvJw4PsZFOLXCRsVVaNq8gAAABXjbOsAQAAVWioBUEAVuhq WQAAv3YHQQBXVuglVQAAV1boHlUAAGiQBUEAVugTVQAAjUNkUFboCVUAAFdW6AJVAABqAWiQ BUEA6BQSAABQVujvVAAAg8REVVbo5VQAAFdW6N5UAABqAmiQBUEA6PARAABQVujLVAAA/7Qk nAAAAFbovlQAAFdW6LdUAABqAOgGJQAAg+ABv6gFQQBAUFfovhEAAFBW6JlUAACDxERqA1fo rBEAAFBW6IdUAACNRCQgUI1DZGoAUOjPGAAAagFofQdBAOiJEQAAUFXoVFQAAI1EJDxQVehZ VAAAg8Q0g6McCQAAAF9eXVuDxGTDVYvsgexoCAAAU1ZXi30MaJAFQQBX6B1UAACLXQiNhZj3 //9QjYWY+///jbPIAAAAUFboaBgAAI2FmPv//1ZQjYWY9///aCsNQQBQ6DBYAACNhZj3//9Q V+jqUwAAvn0HQQBWV+jeUwAAagFokAVBAOjwEAAAUFfoy1MAAIPERI1DZFBX6L5TAABWV+i3 UwAAagJokAVBAOjJEAAAUFfopFMAAI2DLAEAAFBX6JdTAABWV+iQUwAAaJ0HQQBX6IVTAACN g7gIAABQV4lFDOh1UwAAg8RAVlfoa1MAAFZX6GRTAABqB2oUjUWYaghQ6CQTAABqAf91DFfo NQIAAIPELIO7HAkAAACLxnQejUWYUI2FmPf//2j7CEEAUOhgVwAAg8QMjYWY9///UI2FmPv/ /2jhB0EAUOhFVwAAjYWY+///UFfo/1IAAI2DrAEAAFBX6PJSAABoTwhBAFfo51IAAFZX6OBS AABWV+jZUgAAagDoKCMAAIPEOIPgAYO7HAkAAACJRQh1B8dFCAIAAABqAf91DFfomQEAAIPE DI1FmFCNg7AGAABQ/3UIaMEIQQDosQ8AAFlZUI2FmPv//2hnCEEAUOi4VgAAjYWY+///UFfo clIAAFZX6GtSAABWV+hkUgAAjUX8agFQjYOsBQAAUOi6HAAAg8Q4iUUIhcB0ElBX6EFSAAD/ dQjoxFYAAIPEDFZX6C9SAACBw7QHAABZWYA7AA+E6wAAAFPozhgAAD0AyAAAWYlF/HIbPQDQ BwAPg88AAABqAOhRIgAAqAFZD4S/AAAAjUX8agBQU+hOHAAAg8QMiUUIhcAPhKUAAABqAf91 DFfouAAAAGoB/3UMV+itAAAAjYWY+///UI2FmPf//1BqAGoAU+gFUwAAjYWY+///UI2FmPf/ /1Dol1EAAIPENI1FmFCNhZj3//9QagJowQhBAOibDgAAWVlQjYWY+///aGcIQQBQ6KJVAACN hZj7//9QV+hcUQAAVlfoVVEAAFZX6E5RAAD/dQhX6EVRAABWV+g+UQAA/3UI6MFVAACDxEBq AP91DFfoEwAAAGhA8EAAV+gdUQAAg8QUX15bycNVi+xoQPBAAP91COgFUQAA/3UM/3UI6PpQ AACDxBCDfRAAdA9ofQdBAP91COjkUAAAWVldw1WL7IPsMFNWV/8V1NBAAIt9CDPbUFNo/w8f AIld8MdF9DIAAACJXfiIXdiIXdmIXdqIXduIXdzGRd0FiV3oiV3siV38iV3kiR//FSDRQACN TfCJReBRaghQ/xUg0EAAhcB1Dv8V4NBAAIlF/OkSAQAA/3X0U/8VlNBAADvDiUX4dOGNTfRR /3X0UGoC/3Xw/xUw0EAAizXg0EAAhcB1OP/Wg/h6dWv/dfj/FdzQQAD/dfRT/xWU0EAAO8OJ Rfh0UY1N9FH/dfRQagL/dfD/FTDQQACFwHQ6jUXoUFNTU1NTU1NqBI1F2GoBUP8VKNBAAIXA dB2NRexQU1NTU1NTU2oGjUXYagFQ/xUo0EAAhcB1B//W6VH///+LdfiJXQg5HnZSg8YE/3Xo iwaLTgSJRdBQiU3U/xUs0EAAhcB1Iv917P910P8VLNBAAIXAdR3/RQiLRfiLTQiDxgg7CHLH 6xTHReQBAAAAiR/rCccHAQAAAIld5DkfdQs5XeR1BscHAQAAADld7Is1PNBAAHQF/3Xs/9Y5 Xeh0Bf916P/WOV34dAn/dfj/FdzQQAA5XfCLNSTRQAB0Bf918P/WOV3gdAX/deD/1otF/F9e W8nDVYvsuOAtAADoBlcAAFMz2zldEFZXx0X8IAAAAIideP///3QT/3UQjYV4////UOjQTgAA WVnrFWoHagqNhXj///9qBVDomQ4AAIPEEDldGHQF/3UY6wVo5DVJAI2FePr//1DonE4AAIt1 CFlZjYV0/v//VlDoik4AAP91DI2FdP7//1Doi04AAIPEEDldFHQT/3UUjYVw/f//UOhkTgAA WVnrImoBaNwBQQDoQ1YAAGoCmVn3+Y2FcP3//1JQ6FIZAACDxBA5HfA4SQB0HmoBU+gdVgAA agKZWff5jYVw/f//UlDoLBkAAIPEEI2FdP7//1Do/E4AAIC8BXP+//9cjYQFc/7//1l1AogY gL1w/f//XHQTjYV0/v//aETwQABQ6O5NAABZWY2FcP3//1CNhXT+//9Q6NlNAABZjYV0/v// WVNQjYV4+v//UP8VfNBAAIXAD4RlAQAA6JRVAABqBZlZ9/mF0nQi6IVVAACZuQAoAAD3+Y2F dP7//4HCgFABAFJQ6JkWAABZWWh6IgAAjYUg0v//aMDwQABQ6BNSAACNhSDS//+InTTi//9Q jYV0/v//UOj/LAAAjYV0/v//UOgQKwAAg8QYOR3wOEkAD4XqAAAAjUX8UI1F3FD/FWTQQACN RdxQjUYCUOjkngAAWYXAWQ+ExQAAAGoCU1aLNQDQQAD/1ov4O/t1CTldHA+EqgAAAFNTU1ON hXT+//9TUFNqA2gQAQAAjYV4////U1CNhXj///9QV/8VSNBAAFeLPUDQQAD/12oBU/91CP/W i/CNhXj///9qEFBW/xU40EAAU1NQiUUQ/xUk0EAA/3UQiUUY/9dW/9c5XRgPhWUBAAC6gQAA ADPAi8qNvab2//9miZ2k9v//ZomdnPT///OrZquLyjPAjb2e9P//OR0EOUkA86uJXRCJXRhm q3UHM8DpJAEAAItFDIA4XHUHx0UYAQAAAL8EAQAAjYWk9v//V4s1eNBAAFBq//91CGoBU//W i00MjYWc9P//V1CLRRhq/wPBUGoBU//WjUUQUI2FnPT//2oCUI2FpPb//1D/FQQ5SQCFwA+F uwAAAFNTjYV8+///V1CLRRBq/4idfPv///9wGFNT/xWg0EAAjUUUUGgCAACA/3UI/xUc0EAA hcB1d42FrPj//2oDUOgnEQAAjYV8+///aETwQABQ6JNLAACNhXD9//9QjYV8+///UOiASwAA jYV0+f//U1BTjYV8+///U1CInXT5///ov0wAAI2FfPv//1CNhXT5//9QjYWs+P//UP91FOgy GgAAg8Q8/3UU/xVc0EAAoQw5SQA7w3QF/3UQ/9BqAVhfXlvJw1WL7ItFFFNWi/FXM9v/dQiJ RhiNRhyJHlCJXgzo9EoAAIt9EGaLRQxXZomGnAEAAGbHhp4BAAAZAOgWUwAAg8QMO8OJRgR1 DMeGpAEAAAIAAIDrY1fo+lIAADvDWYlGEHTmV1P/dgSJfgiJfhToQ0oAAFdT/3YQ6DlKAACD xBiNjqABAACJnqQBAACJnqgBAABqAWoB/3UMiZ6sAQAAiJ4cAQAA6D4FAACFwHUOx4akAQAA BQAAgDPA6xA5Xgx0CDkedARqAesCagJYX15bXcIQAFaL8VeLRgSFwHQHUOjNTgAAWYtGEIXA dAdQ6L9OAABZjb6gAQAAagBqBmhI8EAAi8/ojAUAAIvP6MEFAACFwHT1g/gBdRBo3QAAAIvO 6NUCAACL8OsDagFei8/okAUAAIvGX17DVovxV2aLhpwBAACNvqABAABQjUYcUIvP6N0EAACF wHUNuAEAAICJhqQBAADrK4vP6GQFAACFwHT1g/gBdQ5o3AAAAIvO6HgCAADrDWoBx4akAQAA AwAAgFhfXsNVi+yB7AQBAABTVovxV42GHAEAAFCNhfz+//9oYPBAAFDopU0AAIPEDI2F/P7/ /42+oAEAAGoAUOg1SgAAWVCNhfz+//9Qi8/otAQAAIvP6OkEAACFwHT1g/gBD4WdAAAAu/oA AACLzlPo+AEAAIXAD4WVAAAAi87olQAAAIXAD4WGAAAAIUX8OQaLfgR2IVeLzug1AQAAhcB1 cFfo0UkAAP9F/I18BwGLRfxZOwZy32oAjb6gAQAAagdoWPBAAIvP6DsEAABoYgEAAIvO6JQB AACFwHU1UIvP/3UM/3UI6B0EAABqAGoFaFDwQACLz+gNBAAAU4vO6GoBAADrDWoBx4akAQAA AwAAgFhfXlvJwggAU1aL8YtGFIPAZFDon1AAAIvYWYXbdQhqAljpmAAAAFVXaHDwQABT6ERI AACLfhAz7TluDFlZdiVXU+hBSAAAaDjwQABT6DZIAABX6BBJAACDxBRFO24MjXwHAXLbaGzw QABT6BhIAABZjb6gAQAAWWoAU+joSAAAWVBTi8/obQMAAIvP6KIDAACL6IXtdPNT6HZMAABZ agFYXzvoXXUOaPoAAACLzuipAAAA6wrHhqQBAAADAACAXlvDU1b/dCQMi9nomUgAAIPAZFDo 308AAIvwWYX2WXUFagJY63JVV2iA8EAAVuiGRwAA/3QkHFbojEcAAGhs8EAAVuiBRwAAg8QY jbugAQAAagBW6FBIAABZUFaLz+jVAgAAi8/oCgMAAIvohe1081bo3ksAAFlqAVhfO+hddQ5o +gAAAIvL6BEAAADrCseDpAEAAAMAAIBeW8IEAFWL7IHsBAQAAFaL8VdqAI2+oAEAAI2F/Pv/ /2gABAAAUIvP6IoCAACLz+ioAgAAhcB09YP4AXVAjUX8UI2F/Pv//2iM8EAAUOgcTwAAi0UI i038g8QMO8F0GseGpAEAAAQAAICJjqgBAACJhqwBAABqAusQM8DrDceGpAEAAAMAAIBqAVhf XsnCBAD/dCQEgcEcAQAAUeiBRgAAWVnCBABVi+xRU1ZXi/H/dQiLfhDoWEcAAINl/ACDfgwA WYvYdhZX6EVHAAD/RfyNfAcBi0X8WTtGDHLqK14Qi0YUA9872HZOi04YA8FQiUYU6GpOAACL 2FmF23UMx4akAQAAAgAAgOs+/3YUagBT6K1FAACLRhCLzyvIUVBT6I5OAACLRhBQK/jojkoA AIPEHIleEAP7/3UIV+jiRQAA/0YMi0YMWVlfXlvJwgQAVYvsUVNWV4vx/3UIi34E6K9GAACD ZfwAgz4AWYvYdhVX6J1GAAD/RfyNfAcBi0X8WTsGcusrXgSLRggD3zvYdk6LThgDwVCJRgjo w00AAIvYWYXbdQzHhqQBAAACAACA6zz/dghqAFPoBkUAAItGBIvPK8hRUFPo500AAItGBFAr +OjnSQAAg8QciV4EA/v/dQhX6DtFAAD/BosGWVlfXlvJwgQAVYvsgeyQAQAAU1ZqAY2FcP7/ /1uL8VBqAv8V4NFAAA+/RQxISHUDagJbD7/DagZQagL/FeTRQAAzyYP4/4kGXg+VwYvBW8nC DABVi+yD7BBWi/H/dQz/FdTRQABmiUXyjUUMUIvO/3UIZsdF8AIA6HkAAACLRQxqEIhF9IpF DohF9opFD4hl9YhF941F8FD/Nv8V2NFAAIXAXnQK/xXc0UAAM8DrA2oBWMnCCAD/dCQM/3Qk DP90JAz/Mf8V0NFAAMIMAP90JAz/dCQM/3QkDP8x/xXM0UAAwgwA/zH/FcTRQAD/JcjRQABq AVjDVYvsUVFTVleLfQhqATP2W4lN+FeJdfzoFUUAAIXAWX4sigQ+PC51Bf9F/OsKPDB8BDw5 fgIz21dG6PNEAAA78Fl83oXbdBiDffwDdAQzwOs6/3UMi034V+g1AAAA6ylX/xXA0UAAi/D/ FdzRQACF9nQWM8CLTgyLVQyLCYoMAYgMEECD+AR87GoBWF9eW8nCCABVi+xRU4tdCFYz9leJ dfyNRQiNPB5QaIzwQABX6NtLAACLVQyLRfyKTQiDxAyD+AOIDBB0F0aAPy50CIoEHkY8LnX4 /0X8g338BHzDX15bycIIAFWL7FFTVlf/dQzoPUQAAIt1CItdEFmJRfxW6C1EAACL+FmF/3Qt hdt0CYvGK0UIO8N9IIN9FAB0D/91DFbo6pQAAFmFwFl0Bo10PgHry4PI/+syi038i8YrRQiN RAgCO8N+CIXbdAQzwOsa/3UMVujoQgAAVujSQwAAg8QMgGQwAQBqAVhfXlvJw1aLdCQIVzP/ OXwkEH4dVuiuQwAAhcBZdBJW6KNDAABHWTt8JBCNdAYBfOOLxl9ew1aLdCQIVzP/VuiEQwAA hcBZdBqDfCQQAHQMi84rTCQMO0wkEH0HjXQGAUfr24vHX17DVYvsUVOLXQhWi3UMV2oAU4l1 /Oi2////i/hZhf9ZfwczwOmVAAAAhfZ9D2oA6KQSAAAz0ln394lV/I1HAlBT6Fr///+L8Cvz 0eZW6F9KAABWM/ZWUIlFDOizQQAAg8QYhf9+JDt1/HQaagH/dRBWU+gp////WVlQ/3UM6JT+ //+DxBBGO/d83DP2Tzv+iTN+H2oB/3UQVv91DOj//v//WVlQU+hs/v//g8QQRjv3fOH/dQzo U0YAAFlqAVhfXlvJw1ZXM/+L92oA994b9oHm+AAAAIPGCOj7EQAAM9JZ9/aLRCQMA8eE0ogQ dQPGAAFHg/8EfNBfXsNVi+yD7AyLRRCDZfgAg30MAFOKCIpAAVZXiE3+iEX/fjOLRQiLTfgD wYlF9IoAiEUTYIpFE4pN/tLAMkX/iEUTYYtN9IpFE/9F+IgBi0X4O0UMfM1qAVhfXlvJw1WL 7IPsDItFEINl+ACDfQwAU4oIikABVleITf6IRf9+M4tFCItN+APBiUX0igCIRRNgikUTik3+ MkX/0siIRRNhi030ikUT/0X4iAGLRfg7RQx8zWoBWF9eW8nDU1ZXM/9X6BsRAABZM9JqGotc JBRZ9/GL8oPGYYP7BHR4g/sBdRVX6PoQAABZM9JqCln38YvCg8Aw62D2wwJ0E1fo4BAAAFkz 0moaWffxi/KDxkFX6M0QAACoAVl0GPbDBHQTV+i9EAAAWTPSahpZ9/GL8oPGYVfoqhAAAKgB WXQY9sMBdBNX6JoQAABZM9JqCln38Yvyg8Ywi8ZfXlvDU4tcJAxWV4t8JBiL8zv7fhJqAOhv EAAAK/sz0vf3WYvyA/OLXCQQM/+F9n4S/3QkHOgr////iAQfRzv+WXzuagLoG////1mIA4Ak HwBqAVhfXlvDVle/kPBAADP2V+iuQAAAhcBZfhiKRCQMOoaQ8EAAdBFXRuiWQAAAO/BZfOgz wF9ew2oBWOv4U4pcJAhWV4TbfD8PvvNW6EhLAACFwFl1NVboa0sAAIXAWXUqv5jwQAAz9lfo VkAAAIXAWX4UOp6Y8EAAdBBXRuhCQAAAO/BZfOwzwOsDagFYX15bw1aLdCQIigZQ/xVo0EAA hcB0C4B+AYB2BWoBWF7DM8Bew4tEJASKADyhdAc8o3QDM8DDagFYw1WL7IHs/AcAAItFHFNW V4t9DDP2iXX8gCcAOXUQiTB/CYtFCEDp3AEAAItdCIoDUOhA////hcBZdVCJXQyDfSAAdCv/ dQzof////4XAWXQN/3UM6JP///+FwFl0Lf91DOiG////hcBZdARG/0UMi0UQRv9FDEg78H0Q i0UMigBQ6PD+//+FwFl0s4tFEEg78IlFDA+NagEAAIoEHlDo0/7//4XAWQ+EvgAAAIoEHlDo i/7//4XAWXULRjt1DHzs6T8BAACKBB5Q6Kj+//+FwFl0G4tN/IoEHv9F/EY7dQyIBDl9CYtF GEg5Rfx814tFGEg5Rfx8HIN9/AB0FotF/IoEOFDoN/7//4XAWXUF/038deqLRfyFwHwEgCQ4 ADPbOB90FYoEO1DoE/7//4XAWXQHQ4A8OwB1640EO1CNhQT4//9Q6MQ9AACNhQT4//9QV+i3 PQAAi0X8g8QQK8M7RRQPjYQAAACLXQiDfSAAD4SKAAAAi0UIgCcAA8Yz21DoR/7//4XAWXRZ i0UQg8D+iUUgi0UIA8aJRRD/dRDoSv7//4XAWXUZi0UQigiIDDuKSAFDRkCIDDtDRkCJRRDr BkZGg0UQAjt1IH0Xi0UYg8D+O9h9Df91EOju/f//hcBZdbiAJDsAO10UfBCLRRzHAAEAAACL RQgDxusMi10Ii0UcgyAAjQQeX15bycNVi+y4HBAAAOgERQAAU1ZXjU3k6OTc//+LfQyNRfhq AVD/dQgz241N5Igf6M/c//+L8DvzD4QrAQAAi1X4g/oKD4IXAQAAiJ3k7///iV38/3UYjU38 Uf91FP91EFJXUOiR/f//i034g8Qci9Er0APWg/oFD47iAAAAOV38dNGJXQgz//91GI1V/CvI UgPO/3UU/3UQUY2N5O///1FQ6FP9//+DxBw5Xfx0A/9FCItN+IvRK9AD1oP6BXYJR4H/ECcA AHy/OV0IdBFT6JgMAAAz0ln394tN+IlVCIv+iV30/3UYjUX8K89QA87/dRSNheTv////dRBR UFfo9/z//4PEHDld/Iv4dBk5XQh0Lv9NCI2F5O///1D/dQzo4jsAAFlZi034i8ErxwPGg/gF dgz/RfSBffQQJwAAfKSNTeTodtz///91DOimPAAAWTPJO0UQD53Bi8FfXlvJw4gfjU3k6FTc //8zwOvtVYvsi1UMUzPbVoXSdAIgGotFEIXAdAOAIACLdQiAPkB0HFeL+ovGK/6KCITJdA6F 0nQDiAwHQ0CAOEB17F+F0nQEgCQTAIA8MwCNBDNeW3UEM8Bdw4N9EAB0C1D/dRDoNDsAAFlZ agFYXcNVi+xRU4pdCFZXvqTwQACNffxmpYD7IKR+NID7fn0vD77zVujKRgAAhcBZdShW6O1G AACFwFl1HYD7QHQYgPsudBM6XAX8dA1Ag/gCfPQzwF9eW8nDagFY6/b/dCQE6J3///9Zw1WL 7LgAIAAA6MtCAAD/dQiNhQDg//9Q6Kw6AAD/dQyNhQDw//9Q6J06AACNhQDg//9Q6O2MAACN hQDw//9Q6OGMAACNhQDw//9QjYUA4P//UOjCRgAAg8QgycNWvlICQQBW/3QkDOhdOgAA/3Qk FFbogff//1D/dCQc6Fk6AACDxBhew1OLXCQIVldT6Cc7AACL+FmD/wR8JIP/DH8fM/aF/34U D74EHlDoDUYAAIXAWXQKRjv3fOxqAVjrAjPAX15bw1WL7IHsBAEAAFNWV42F/P7//zP/UFdX V/91COhQOwAAvvwBQQBXVug39///i9iDxBw7334gV1bo9/b//1CNhfz+//9Q6IyLAACDxBCF wHQnRzv7fOCNhfz+//9owg1BAFDob4sAAPfYG8BZg+BjWYPAnF9eW8nDi8fr91WL7FYz9ldW aiBqAlZqA2gAAADA/3UI/xX80EAAi/iJdQiD//90Izl1DHQejUUIVlD/dRD/dQxX/xVs0EAA V/8VJNFAAGoBWOsCM8BfXl3DVYvsU1dqAGonagNqAGoDaAAAAID/dQj/FfzQQACDZQgAi/iD y/87+3QdjUUIUFf/FezQQACDfQgAi9h0A4PL/1f/FSTRQACLw19bXcNVi+yD7BSNTezo2tj/ /41F/GoBUI1N7P91COjM2P//hcB0DY1N7Oh62f//agFYycMzwMnDVYvsgewYAQAAVmoEagWN RexqAlDof/j//4PEEI2F6P7//1BoBAEAAP8VmNBAAIt1CI1F7FZqAFCNhej+//9Q/xV00EAA VugjAAAAVuhYOQAAWVlIeAaAPDAudfcDxmjcAUEAUOhQOAAAWVleycNqIP90JAj/FYDQQAD/ dCQE/xWc0EAAw1WL7IHsSAMAAFZX/3UIjYX4/f//M/ZQ6Bg4AACNhfj9//9Q6Pw4AACDxAyF wHQXgLwF9/3//1yNhAX3/f//dQaAIABqAV6Nhfj9//9osPBAAFDo7TcAAFmNhbj8//9ZUI2F +P3//1D/FYzQQACL+IP//w+E1AAAAP91CI2F/P7//1DorTcAAFmF9ll1E42F/P7//2hE8EAA UOimNwAAWVmNheT8//9QjYX8/v//UOiRNwAA9oW4/P//EFlZdFuNheT8//9orPBAAFDodTYA AFmFwFl0Wo2F5Pz//2io8EAAUOheNgAAWYXAWXRD/3UQjYX8/v//agFQ/1UMg8QMhcB0Lf91 EI2F/P7///91DFDo7P7//4PEDOsW/3UQjYX8/v//agBQ/1UMg8QMhcB0Fo2FuPz//1BX/xWI 0EAAhcAPhTP///9X/xWE0EAAXzPAXsnDVYvsUYF9DABQAQBTVld8Kmog/3UI/xWA0EAAM9tT aiBqA1NqA2gAAADA/3UI/xX80EAAi/iD//91BzPA6YQAAACNRfxQV/8V7NBAAIvwO3UMfhVT U/91DFf/FeTQQABX/xWQ0EAA61NqAlNTV/8V5NBAAItFDCvGvgAACACJRQiLzpn3+TvDix1s 0EAAfheJRQyNRfxqAFBWaNAxQQBX/9P/TQx17I1F/GoAUItFCJn3/lJo0DFBAFf/01f/FSTR QABqAVhfXlvJw1ZqAGonagNqAGoDaAAAAID/dCQg/xX80EAAi/CD/v91BDPAXsOLRCQMV41I EFGNSAhRUFb/FejQQABWi/j/FSTRQACLx19ew1ZqAGonagNqAGoDaAAAAMD/dCQg/xX80EAA i/CD/v91BDPAXsOLRCQMV41IEFGNSAhRUFb/FTDRQABWi/j/FSTRQACLx19ew1WL7IPsFFON TezodNX//41F/GoBUI1N7P91COhm1f//i9iF23Rwg30QAHQmgX38AJABAHYdagDosgUAAFkz 0moKWffxg8JUweIKO1X8cwOJVfyLRfxWA8BQ6Gk9AACL8FmF9nQmi0X8A8BQagBW6LU0AABq SP91/FZT6LnN//+LTQyDxByFyXQCiQGNTezordX//4vGXlvJw1WL7IHsBAEAAFNWV4t9CDPb ahRTV4id/P7//+hvNAAAg8QMOB3sN0kAdD5T6CQFAABZM9JqA1n38YXSdCxqAWoKjYX8/v// UVBo7DdJAOib9///g8QUhcB0D42F/P7//1BX6Ig0AABZWTgfD4WLAAAAOB3oNkkAdDZT6NYE AABZM9JqA1n38YXSdCSNhfz+//9TUFNTaOg2SQDouzUAAI2F/P7//1BX6EM0AACDxBw4H3VJ U+icBAAAqA9ZdSu+dA1BAFNW6IPx//9TiUUI6IIEAAAz0vd1CFJW6D7x//9QV+gJNAAAg8Qc OB91D2oEagZqAlfo1fP//4PEEDldDHQrvvwBQQBTVuhA8f//U4lFCOg/BAAAM9L3dQhSVuj7 8P//UFfo1jMAAIPEHDldEHQN/3UQV+jFMwAAWVnrMDldFHQrvtwBQQBTVuj+8P//U4lFCOj9 AwAAM9L3dQhSVui58P//UFfolDMAAIPEHF9eW8nDVYvsg+wUU4tFGFZX/3UUM9uDz/+JXfxT iX34/3UQiV3wiV30iRjo8TIAAIt1CIoGUOgZ+P//g8QQhcAPhIwAAACKBlDoBvj//4XAWXRc i0UMi95IiUUIi0UQK8aJRezrA4tF7IoLiAwYigM8QHUJi03w/0X0iU34PC51B4X/fQOLffD/ RfxDi0X8/0XwO0UIfRaLRRRIOUXwfQ2KA1DorPf//4XAWXW5M9uLRfCLTRArffiAJAgAg/8D fhFqAVg5Rfh+CTlF9A+EoAAAAINN+P+DTfD/iV38ZoseM/9TIX306MP3//+FwFkPhIoAAABT 6LT3//+FwFl0VItFDEghfQyJRQiLRRCA+0CIHAd1Bv9F9Il9+ID7LnUJg33wAH0DiX3wg0UM BINF/AKLRQxHO0UIfRqLRRRIO/h9EotF/GaLHDBT6GD3//+FwFl1totFEIAkBwCLRfArRfiD +AJ+EmoBWDlF+H4KOUX0dQWLTRiJAYtF/APG6wONRgFfXlvJw1WL7IHsGAQAAFMz21aNTeiJ Xfzo3tH//41F+GoBUI1N6P91COjQ0f//i/A783UEM8DrY1eL/otF+IvPK86NUP87yn1HjU38 K8dRjY3o+///aAAEAACNRDD/UVBX6B7+//+DxBSDffwAi/h0yv91FI2F6Pv///91EFD/dQzo Hu7//4PEEIXAfq5D66uNTejoINL//4vDX15bycNVi+xRUYtFGINN+P9QagD/dRSJRfzo5zAA AIPEDI1FGFD/dQz/dQj/FUzQQACFwHQFagFYycONRfxQjUX4/3UUUGoA/3UQ/3UY/xUU0EAA /3UY/xVc0EAAM8DJw1WL7I1FDFD/dQz/dQj/FRjQQACFwHQFagFYXcP/dRTo0TEAAFlQ/3UU agFqAP91EP91DP8VENBAAP91DP8VXNBAADPAXcNVi+yB7AwBAACNRfxWUDP2/3UM/3UI/xVM 0EAAhcB0BDPA61eNhfT+//9oBAEAAFBW/3X8/xVQ0EAAhcB1LzlFEHQjIUX4/3UUjUX4UI2F 9P7//1D/dQz/dQj/VRCDxBSDffgAdQNG67uL8OsDagFe/3X8/xVc0EAAi8ZeycNVi+yB7BQI AABTjUX8VlD/dQy+AAQAADPbiXXw/3UIiXX4/xVM0EAAhcB0BDPA63ONRfiJdfBQjYXs9/// UI1F7FCNRfBqAFCNhez7//+JdfhQU/91/P8VRNBAAIXAdTWDfewBdSg5RRB0IyFF9P91FI1F 9FCNhez7//9Q/3UM/3UI/1UQg8QUg330AHUDQ+ufi/DrA2oBXv91/P8VXNBAAIvGXlvJw4N8 JAQAdQmDPcwxQQAAdRf/FTTRQABQ6GM3AABZ6Gc3AACjzDFBAOldNwAAVYvsg+xUVjP2akSN RaxWUOj5LgAAg8QMjUXwx0WsRAAAAFCNRaxQVlZWVlZW/3UM/3UI/xWk0EAA99gbwF4jRfDJ w1WL7IPsHFNWjU3k6BbP//+DZfgAvsDwQABW6PwvAABZiUX0jUX8agFQjU3k/3UI6PXO//+L 2IXbdFOLTfxXgfkAoAAAcju4ABAAAIHBGPz//zvIi/h2Kv919I0EH1BW6Jc7AACDxAyFwHQP i0X8RwUY/P//O/hy3+sHx0X4AQAAAI1N5Ohaz///i0X4X15bycNVi+yB7AAEAABojQdBAP91 EOi88///WYXAWXRzjYUA/P//aAAEAABQgKUA/P//AP91EP91DP91COj8/P//jYUA/P//UOgm ////g8QYhcB0P4tNGGoBWP91DIkBi00UaOA0SQCJAegwLgAAjYUA/P//UGjkNUkA6B8uAAD/ dRBo3DNJAOgSLgAAg8QYM8DJw2oBWMnDVYvsgewACAAA/3UMjYUA/P//UOjuLQAAjYUA/P// aETwQABQ6O0tAAD/dRCNhQD8//9Q6N4tAACNhQD8//9ojQdBAFDo9fL//4PEIIXAdHmNhQD4 //+ApQD4//8AaAAEAABQjYUA/P//aJMHQQBQ/3UI6C78//+NhQD4//9Q6Fj+//+DxBiFwHQ/ i00YagFY/3UMiQGLTRRo4DRJAIkB6GItAACNhQD4//9QaOQ1SQDoUS0AAP91EGjcM0kA6EQt AACDxBgzwMnDagFYycNVi+yB7BwFAACDZfwAgz3wOEkAAHUlagRoUgJBAOhE6v//jU38UWhK SUAAUGgCAACA6EP8//+DxBjrPI2F6Pv//2oCUOiC8v//jYXo+///UGjgNEkA6N4sAACNRfxQ jYXo+///aLZIQABQaAIAAIDog/z//4PEIItF/IXAo/Q4SQAPhdEAAABWjYXk+v//aAQBAABQ /xWo0EAAM/aAZegAjUXoaI0HQQBQ6IosAABZjUXoWWoEagRqAlDoaS0AAFmNRAXoUOhN7P// jUXpUOjBfgAAjYXk+v//UI2F6Pv//1DoUiwAAI2F6Pv//2hE8EAAUOhRLAAAjUXoUI2F6Pv/ /1DoQSwAAI2F6Pv//2jcAUEAUOgwLAAAjYXo+///UOgn8///g8Q4hcB0CkaD/goPjGf///+N RehQaNwzSQDoBSwAAI2F6Pv//1Bo5DVJAOjkKwAAg8QQXmoBWMnDi0QkBGaLTCQIZgFIAmaL SAJmg/kBfQ5mg0ACHmaLSAJm/wjr7GaDeAIffhJmg0AC4maLSAJm/wBmg/kff+5miwhmg/kB fQaDwQxmiQhmiwhmg/kMfgaDwfRmiQjDi0QkDFaLdCQIV4t8JBCAJwCAIACAPlx1WIB+AVx1 UlNouPBAAFfoUysAAFmNRgJZighqAoD5XFp0F4vfK96EyXQPighCiAwDikgBQID5XHXtgCQ6 AAPWW4A6AHUEagLrElL/dCQY6BMrAABZM8BZ6wNqAVhfXsNVi+yB7BAEAABWjYX0/P//aOQ1 SQBQ6OwqAABZjYX8/v//WTP2aAQBAABQVv8VFNFAAFaNhfD7//9WUI2F9Pz//1ZQ6CosAABW jYX4/f//VlCNhfz+//9WUOgULAAAjYX4/f//UI2F8Pv//1DoZnwAAIPEMPfYG8BeQMnDVot0 JAyD/kRyMYtMJAiAOU11KIB5AVp1Ig+3QTwDwYPG/IvQK9E71ncRiwBeLVBFAAD32BvA99Aj wsMzwF7DVYvsU4tdEFaLdQhXU1borv///1mFwFl0UI0MMIt1DItRdI1BdDvWckAPt0kGi3Tw /IPABDP/hcmNRNAIdiuDw/yJXRCL0CtVCDtVEHMbi1AEixgD2jvedgQ71nYIg8AoRzv5ct87 +XICM8BfXltdw1WL7FNWi3UMV4t9CI1GEIlFDIvGK8eDwBA7RRgPh4AAAAAPt0YOD7dODINl CAADwYXAfmaLXRSLRQyLTRgrx4PACDvBd1SLRQyLQASpAAAAgHQcUVP/dRAl////fwPHUFfo mv///4PEFIXAdDXrFYvTA8crVRABEIsAO8NyJAPLO8FzHg+3Rg4Pt04Mg0UMCP9FCAPBOUUI fJ1qAVhfXltdwzPA6/dVi+yD7DxWjU3U6CLJ//+NTcToGsn//41F/GoBUDP2/3UMjU3EiXX4 iXX8iXX0iXXw6P7I//87xolFDHUHM8DpZAEAAItF/ItNEFONhAgAEAAAUP91COj58f//WY1F +FlWUP91CI1N1OjHyP//i9g73old7A+E/gAAAFf/dfhqA1PoZP7//4v4g8QMO/4PhNoAAAD/ dfxqA/91DOhK/v//i/CDxAyF9g+EwAAAAP91/P91DOjz/f///3X4iUUQU+jn/f//i00Qi1UM A8qDxBBmg3lcAg+FkwAAAIuJjAAAAAPYiU0QiYuMAAAAi0YIi08MiUcIiwaJB4tHCAPBiUXw i0YEiUXki0cEiUXoi0YIi3YMA/KLVeyNPBGLyCtNDAPOO038d0dQVlfouCwAAP91EP916P91 5FdX6Bz+//8Pt0sUiUX0i9MPt0MGA9GDxCCNBICNTML4i0TC/AMBZqn/D3QHwegMQMHgDIlD UI1N1Oh5yP//M/ZfjU3E6G7I//85dfRbdB+LRfA7RfxzA4tF/FD/dQjouvD///91COhMAQAA g8QMi0X0XsnDVYvsg+wUU1aNTezodsf//zP2jUX8VlD/dQiNTezoZ8f//4vYO951BzPA6b0A AABX/3X8U+jH/P//i/hZhf9ZD4SBAAAA/3X8agNT6O/8//+DxAyFwHRvahCNNB9aiZaMAAAA i0gEA8qJEGb3wf8PiVAIdAfB6QxBweEMiU5Qi0gMi3gIA/k7fQxzA4t9DGb3x/8PdAfB7wxH wecMjQQZi8gryztN/HMMUmoAUOh6JgAAg8QMi4bsAAAAhcB0A4lGKGoBXusDi30IjU3s6HLH //+F9nQLV/91COjL7///WVn/dQjoWwAAAFmLxl9eW8nDVYvsUYtFDDPJ0eiJTfx0KYtVCFaL 8A+3AgPIiU0Ii0UIwegQiUUIgeH//wAAA00IQkJOdeGJTfxeiU0Ii0UIwegQi1X8ZgPCiUUI i0UIA0UMycNVi+yD7BRWV41N7Ogzxv//g2X8ADP2jUX8VlCNTez/dQjoIMb//4v4hf90O/91 /FfoiPv//1mFwFl0IoN8OFgAjXQ4WHQSgyYA/3X8V+hb////WYkGWesDi0UIi/CNTezom8b/ /4vGX17Jw1WL7IHsAAgAAIM98DhJAAB1NYM9EDlJAAB0LI2FAPj//2jIAAAAUGr//3UIagFq AP8VeNBAAI2FAPj//1BqAP8VEDlJAMnDM8DJw1WL7IPsDFNWV4tFCIlF+ItFDIlF9It1+It9 9FFSUzPJSYvRM8Az26wywYrNiuqK1rYIZtHrZtHYcwlmNSCDZoHzuO3+znXrM8gz00911ffS 99Fbi8LBwBBmi8FaWYlF/ItF/F9eW8nDVYvsgexQAQAAU1ZXagNfjU3Q6A7F////dRDo+yUA AIvwWY1F6IPGIFD/FdjQQABmgWXq/v8z21PoU/X//1kz0moeWffxZilV8maDffI8cgZmx0Xy AQCKRfKLTfCD4D/B4QYLwYpN9NDpweAFg+EfC8GKTf5miUX8i0Xog8BEg+EfweAJM8GKTeqD 4Q9mJR/+weEFC8GKTe5miUX+Mk3+g+EfZjPBOV0UZolF/nQDagJfaiD/dQj/FYDQQABTaiBX U2oDaAAAAMD/dQj/FfzQQACL+IP//4l9+HQqagJTU1f/FeTQQACNReRqAVCNTdD/dQzoMcT/ /zvDiUUMdQ5X/xUk0UAAM8Dp8wAAAItF5MaFsv7//3RQZseFs/7//wCA/3UMZom1tf7//4mF t/7//4mFu/7//4idv/7//+hX/v///3UQiYXA/v//i0X8xoXI/v//FImFxP7//8aFyf7//zDo tCQAAP91EGaJhcr+//+NhdD+//+Jncz+//9Q6KgjAAAPt/6NR/5QjYWy/v//UOgD/v//izVs 0EAAg8QcOV0UZomFsP7//3QRjUXgU1BqFGisDUEA/3X4/9aNReBTUI2FsP7//1dQ/3X4/9aN ReBTUP915P91DP91+P/WjU3Q6P3D////dfj/FSTRQAA5XRR0Cf91COgBAQAAWWoBWF9eW8nD VYvsUYsNFDlJAINl/ABqAYXJWHQIjUX8agBQ/9HJw1WL7IHsYAYAAItFCFMz28dF8EAGAAA7 w4ld/HUG/xWs0EAAjU0IUWooUP8VINBAAIXAD4SeAAAAVo1F9FdQ/3UMU/8VCNBAAIXAdHyL RfSLNQzQQACJReSLRfiJReiNRfBQjYWg+f//UI1F4GoQUFOJXeD/dQiJXez/1os94NBAAP/X hcB1QYtF9IONrPn//wKJhaT5//+LRfiJhaj5//9TU42FoPn//2oQUFPHhaD5//8BAAAA/3UI /9b/14XAdQfHRfwBAAAA/3UI/xUk0UAAi0X8X15bycNVi+yD7BhWM/ZXVmogagNWagFoAAAA wP91CP8V/NBAAIv4O/4PhK4AAACNRehQ/xW00EAAVuha8v//ajwz0ln38VZmiVXy6Eny//9Z M9JZahhZ9/FmKVXwZjl18H8IZgFN8Gb/Te5W6Cjy//9ZM9JqHFn38WYpVe5mOXXufxJW6BDy //9ZM9JqA1n38WaJVe5W6P7x//9ZM9JqDFn38WYpVepmOXXqfwhmAU3qZv9N6I1F+FCNRehQ /xWw0EAAjUX4UI1F+FCNRfhQV/8VMNFAAFf/FSTRQABfXsnDVYvsgeyUAAAAU1ZXagFbU+ij 8f//vgQBAAAz/1ZXaOw3SQDoyiAAAFZXaOg2SQDoviAAAFZXaOQ1SQDosiAAAFZXaOA0SQDo piAAAFZXaNwzSQDomiAAAIPEQGjQ8EAAaGYiAABo1PBAAOjH3///aPg4SQDoCdD//4PEEP8V vNBAACUAAACAiT0AOUkAo/A4SQCNhWz///9Qx4Vs////lAAAAP8VuNBAAIO9cP///wV1Djmd dP///3UGiR0AOUkA6FXz//++ANAHAFbowSgAADvHWaPYM0kAdQQzwOskVldQ6AwgAADo1QAA AFNoBA5BAOiK3f//UFfoTv3//4PEHIvDX15bycNVi+yD7BRXjU3s6DfA//+NRfxqAFCNTez/ dQjoKcD//4v4hf8PhIwAAABWvgAQAAA5dfxzBDP263JT/3UM6PkgAACL2ItF/AUY/P//WTvG dlaNBD5TUP91DOi9LAAAg8QMhcB0D4tF/EYFGPz//zvwct/rM418PhS+ZiIAAI1f/FNWV+in 3v//i0UMVoPAFFBX6GUkAABT6ADe//9TVlfoL97//4PEKGoBXluNTezoUMD//4vGXl/Jw1NV VldqAmiTC0EA6LDc//+LHfTQQABZWVD/04s1ONFAAIvohe2/kwxBAHQ5agFX6Izc//9ZWVBV /9ZqBFejCDlJAOh53P//WVlQVf/WagVXowQ5SQDoZtz//1lZUFX/1qMMOUkAagNokwtBAOhP 3P//WVlQ/9OL6IXtdBNqA1foPNz//1lZUFX/1qMQOUkAv8gNQQBX/9OL2IXbdBNqAVfoG9z/ /1lZUFP/1qMUOUkAX15dW8NVi+yB7EwGAABTVleNTeToxL7//4t9CDPbV4ld9OiQ7///hcBZ D4VqAgAAV+jP+P//hcBZD4VbAgAAvvsMQQBTVuj12///iUX8jYW4+v//U1BTU1fo7x8AAIPE HDld/IldCH4x/3UIVuie2///OBhZWXQXUI2FuPr//1DoleP//1mFwFkPhQsCAAD/RQiLRQg7 Rfx8z42FyP7//1Dog+X//42FvPv//8cEJAQBAABQU/8VFNFAAI2FyP7//1NQjYW8+///UP8V fNBAAIXAD4TCAQAAizWA0EAAjYXI/v//aiBQ/9ZoAFABAI2FyP7//1dQ6LH0//+DxAyFwA+E hwEAAI1F+FNQV41N5OjMvf//O8OJRQgPhG4BAACBffgAUAEAD4ZZAQAAgX34AAAwAA+DTAEA AI2FvPv//1NQjYW0+f//UI2FxP3//1BX6PgeAACNhbT5//9QjYXE/f//UOiKHQAAjYW8+/// UI2FxP3//1Dodx0AAI2FxP3//2is8EAAUOhmHQAAagRqA42FwPz//2oDUOgj3f//D76FwPz/ /1DotSAAAIPEQIiFwPz//42FwPz//1CNhcT9//9Q6CsdAACNRfRQ/3X4/3UI6BkaAACDxBQ7 w4lFCI1N5A+EoQAAAOiuvf///3X0jYXE/f///3UIUOha4///jYXE/f//UOiq+v//g8QQjYXE /f//aidQ/9aNRcxQV+io5v//WYlF/FlqIFf/1lONhcj+//9XUP8VfNBAAI2FyP7//1DoUOT/ /42FxP3//1Bo1ABBAOiKHAAAaMDwQABX6DT8//+DxBQ5Xfx0DI1FzFBX6J3m//9ZWf91COj+ IAAAWWoBWOsXjU3k6A29//+Nhcj+//9Q6P7j//9ZM8BfXlvJw1WL7IHsKAQAAFaNTejoKrz/ /4Nl/ACNRfhqAVD/dQiNTejoGLz//4vwhfYPhJMAAACNheD9//9QjYXY+///UI2F3Pz//1CN heT+//9Q/3UI6FcdAACNhdz8//9QjYXk/v//UOjpGwAAjYXY+///UI2F5P7//1Do1hsAAICl 5f3//wCNheH9//9QjYXk/v//UOi8GwAAjYXk/v//aNwBQQBQ6KsbAACNRfxQ/3X4VuiqGQAA i/CDxECF9o1N6HUJ6DW8//8zwOtU6Cy8////dfyNheT+//9WUOja4f//Vuj5HwAAg8QQM/b/ FcTQQABQjYXk/v//UOjY6///WYXAWXQZav9Q/xXA0EAAjYXk/v//UOjg4v//WWoBXovGXsnD VYvsgewEAQAAjYX8/v//aAQBAABQaKAxQQBqBWhSAkEA6CrY//9ZWVBoAQAAgOiO6f//agGN hfz+////dQz/dQhQ6ODo//+DxCTJw1WL7IHsDAIAAFMz2zldDFZXiV38D4WLAQAAvosJQQBT VugO2P//i/iNhfT9//9QjYX4/v//UFNTiJ34/v///3UI6PsbAACDxBxPO/uJXQx+Mf91DFbo qtf//1CNhfj+//9Q6D9sAACDxBCFwHUMOX0MdAfHRfwBAAAA/0UMOX0MfM+NhfT9//9QjYX4 /v//UOhRGgAAvhsLQQBTVuiT1///g8QQM/87w4lFDH4oV1boUNf//1CNhfj+//9Q6OVrAACD xBCFwHUHx0X8AQAAAEc7fQx82Dld/HQpagFo8A1BAOge1///i3UIUFboHt///4PEEIXAdQ9W 6I7h//9Z6aIAAACLdQhW6MXf//+L+Fk7+3w1VmjoNkkA6LgZAABZg/8FWX02VmjsN0kA6KYZ AABqAWgA0AcA/zXYM0kAVuiY5///g8QY6xOD/5x1DlNq/2r/Vuh6EgAAg8QQixUYOUkAadIs AQAAgfpYGwAAfhdT6Mfp//9ZM9JqBVn38YPCB2nS6AMAAFL/FSzRQAD/BRg5SQCBPRg5SQAQ JwAAfgaJHRg5SQBqAVhfXlvJw1WL7IHsDAMAAFMz242F9Pz//1NQjYX8/v//UFP/dQjocBoA AIPEFDldDHVtOV0QdT+Nhfz+//9Q6NwZAAA7w1l0B4icBfv+//+Nhfj9//9TUFONhfz+//9T UOg1GgAAjYX4/f//UOh63v//g8QY6w2NhfT8//9Q6Gne//9ZhcB0GGoBaADQBwD/NdgzSQD/ dQjomOb//4PEEGoBWFvJw1ZXi3wkDGoBXmhuCUEAV+iu3f//WYXAWXQlaG0JQQBX6J3d//9Z hcBZdAIz9lZoJ15AAFfoHeD//4PEDGoBWF9ew1WL7IHsDAsAAItFFFNWV/91DDPbiRiNhfT0 //9Q6CYYAACNhfT0//9oRPBAAFDoJRgAAP91EI2F9PT//1DoFhgAAI2F9Pj//2gABAAAUI2F 9PT//1NQaAIAAIDoh+b//42F9Pj//1CNhfz+//9Q6NUXAACDxDSNhfT4//9oBAEAAFCNhfz+ //9Q/xXI0EAAvosJQQBTVugL1f//iUUUjYX0/P//U1BTjYX0+P//U1Do/xgAAIPEHDP/OV0U fitXVuix1P//OBhZWXQTUI2F9Pz//1DoqNz//1mFwFl1Bkc7fRR82jt9FHwkjYX0+P//aCMN QQBQ6Ibc//9ZhcBZdA2NhfT4//9Q6F/4//9ZU42F+P3//1NQjYX8/v//UI2F9Pj//1DoihgA AI2F+P3//1CNhfz+//9Q6BwXAACNhfz+//9Q6Hb+//+DxCBo6AMAAP8VLNFAAGoBWF9eW8nD VYvsgewIAQAAgKX4/v//AI2F+P7//2oBUOhf3P//jUX8UI2F+P7//2gIX0AAUGgCAACA6PPl //+DxBhogO42AP8VLNFAAOvBVYvsg30MAHU0g30QAHUIagX/FSzRQAD/dQjoftz//4XAWXwU g/gDfQ//dQho7DdJAOhsFgAAWVlqAVhdw/91COjT/f//hcBZdAQzwF3DM8A5RRAPlMBdw1WL 7IHsDAEAAICl9P7//wBTjYX0/v//aAQBAABQagFobQlBAOhP0///WVlQaFICQQBoAgAAgOiu 5P//jYX0/v//UOh5/f//D76F9P7//4qd9v7//1DobhkAAIPEHINl+ACIRf+KRfgEYTpF/3Q8 gKX2/v//AIiF9P7//42F9P7//1D/FczQQACD+AOInfb+//91F/91CI2F9P7//2iuYEAAUOhv 3f//g8QM/0X4g334GnyxM8BbycIEAFZohQlBAP90JBDogRUAAIt0JBBW6GcWAACDxAwzyYXA fguAPDFAdAVBO8h89Ug7yHwEM8Bew41EMQFQ/3QkEOhcFQAAWVlqAVhew1WL7IHsFAIAAIA9 1DJJAABWD4SbAAAAgD3QMUkAAA+EjgAAAIN9EACLdQh0ElboA7b///91DFbo0sD//4PEDGpk aAABAABqGWjUMkkAjY3s/f//6NjJ//9qBGoKjUWcagNQ6L3U//+DxBCNRZyNjez9//9Q6DvO //+DxmSNjez9//9W6OrO//9o0DFJAI2N7P3//+gxzv//jY3s/f//6MTK//+FwHQQjY3s/f// 6FDK//8zwF7Jw/91DOh2FQAAWVCNjez9////dQzo9Mr//42N7P3//4vw6CbK//8zwIX2D5TA 689Vi+yB7BgDAABWi3UIjYXo/P//UFbotv7//1mFwFl1BzPA6boAAACDfRAAdBJW6B61//// dQxW6O2///+DxAxqZGgAAQAAjYXo/P//ahlQjY3s/f//6PHI//9qBGoKjUWcagNQ6NbT//+D xBCNRZyNjez9//9Q6FTN//+NRmSNjez9//9Q6APO//9WjY3s/f//6E7N//+Njez9///o4cn/ /4XAdBCNjez9///obcn//+lr/////3UM6JMUAABZUI2N7P3///91DOgRyv//jY3s/f//i/Do Q8n//zPAhfYPlMBeycNVi+yB7AAIAACApQD4//8AgKUA/P//AI2FAPj//1D/dQjoxv3//42F APz//1D/dQzot/3//42FAPz//1CNhQD4//9Q6ARlAACDxBj32BvAQMnDg+wQVVZXg0wkGP+9 ABAAAGoBVb7U8EAA/3QkKDP/iXwkIFbops///4PEEIXAD4XvAAAAV1boTtD//1k7x1mJRCQQ D46yAAAAUzPbhf+JXCQQfjNTVuj+z///WVlQV1bo9M///1lZUOhC////WYXAWXQIx0QkEAEA AABDO9981IN8JBAAdUxqAY1fATtcJBhYiUQkEH0uU1bou8///1lZUFdW6LHP//9ZWVDo//7/ /1mFwFl0BP9EJBBDO1wkFHzWi0QkEDtEJBh+CIlEJBiJfCQcRzt8JBQPjGz///+DfCQYAFt+ FYN8JBgAfA5V/3QkHFbow8///4PEDDP/agFV/3QkKFboxc7//4PEEIXAdRJVav9W6KHP//+D xAxHg/8KfNpqAVhfXl2DxBDDgewEAgAAU1VWV8dEJBABAAAAMtu+Xg5BAL0EAQAAvwEAAID/ dCQQjUQkGIgd1DJJAIgd0DFJAFZo6ChBAFDoBBYAAIPEEFVo1DJJAGoBVujYzv//WVlQjUQk IFBX6Dvg//+DxBQ4HdQySQB0J1Vo0DFJAGoCVuixzv//WVlQjUQkIFBX6BTg//+DxBQ4HdAx SQB1F/9EJBCDfCQQCX6EiB3UMkkAiB3QMUkAX15dW4HEBAIAAMNVi+y4IDAAAOhLGQAAU1ZX aAAAEADobRkAADPbWTvDiUXsdQlfXjPAW8nCBADo8O3//4XAdQ1oYOoAAP8VLNFAAOvqaADQ BwD/NdgzSQDo0/X//1lZagHoovr//+jp/v//jYWI8///aAQBAABQU/8VFNFAAI2F3P7//1Do D9j//1mJXfi+JAkAAOiU7f//hcB1Cmhg6gAA6YcDAACNhdz+//9Q6LPX//+FwFl1Wo2F3P7/ /1NQjYWI8///UP8VfNBAAI2F3P7//2ogUP8VgNBAAI2F3P7//2gAUAEAUOjb6P//U+jG4P// M9K5ACgAAPfxjYXc/v//gcIAUgEAUlDoYtn//4PEFFP/NdgzSQDok83//zlF+FlZiUXoD439 AgAAaHoiAACNheDP//9owPBAAFDowRQAAI2F4M///4id9N///1CNhdz+//9Q6K3v//9WjYWM 9P//U1Doig8AAP91+P812DNJAOgKzf//g8QoOBiJReQPhJUCAABQjYXw9P//UOjBDwAAU+gh 4P//M9KDxAz3deg7Vfh1AUI7Veh8AjPSUv812DNJAOjIzP//i/hZWTgfdRBT/zXYM0kA6LTM //9Zi/hZjYXc/v//UI2FOPr//1Dobw8AAI2FVPX//1dQ6GIPAACNhYz0//9XUOhVDwAAagGN hYz0////dexQ6P/5//+DxCSFwA+FAAIAAFaNhYz0//9TUOjLDgAAjYXc/v//UI2FOPr//1Do GA8AAI2FVPX//1dQ6AsPAACNhYz0//9XUOj+DgAA/3XkjYXw9P//UOjvDgAAagGNhYz0//// dexQ6H76//+DxDiFwHQMV+in+///WemSAQAAU2jU8EAA6B7M//+DTeD/WVmJRfSJXfBWjYWM 9P//U1DoRg4AAI2F3P7//1CNhTj6//9Q6JMOAACNhVT1//9XUOiGDgAA/3XkjYXw9P//UOh3 DgAAU+jX3v//M9KDxCj3dfQ7VeCJVfx1BEKJVfw7VfR8A4ld/P91/GjU8EAA6HbL//9QjYWM 9P//UOg7DgAAagGNhYz0////dexQ6Mr5//+DxByFwHUT/0Xwi0X8g33wBolF4A+MXP///4N9 8AYPjM0AAABTaCwOQQDoWcv//1OJRfToWN7//zPSg8QM93X0O1X0iVX8fAOJXfyNhVzy//9Q jYWw/f//UFfoM9L//42FsP3//2g08EAAUOjKDQAA/3X8aCwOQQDo28r//1CNhbD9//9Q6LAN AABWjYWM9P//U1DoMg0AAI2F3P7//1CNhTj6//9Q6H8NAACNhVT1//9XUOhyDQAAg8RAjYXw 9P///3XkUOhgDQAAjYWw/f//UI2FjPT//1DoTQ0AAGoBjYWM9P///3XsUOjc+P//g8Qc/0X4 i0X4O0XoD4wD/f//aMAnCQD/FSzRQADpW/z//1WL7IHsYAUAAGah9ChBAFZXagdmiUWgWTPA jX2i86tmq6HwKEEAjX3oiUXkM8CrZqsz/8dF4CAAAAA5PfA4SQCJffSJffgPhd8BAAA5PQg5 SQAPhNMBAACLdQg793QljUXgUI1FgFD/FWTQQACNRYBQjUYCUOhwXgAAWYXAWQ+EpwEAAI2F WP///4NN0P+JRdiNhbD+//+JRcCNhbD+//+JRciNRYBTUI1FoIl9xFCJfdSJfdzHRcx/AAAA 6GkMAABZjYUY////WWoiUGr/Vos1eNBAAGoBV//Wx0X8AgAAALtE8EAAikX8ahQEQYhF5I2F WP///1CNReRq/1BqAVf/1opF5Go0iEWgjYWw/v//UI1FoGr/UGoBV//WjUX0UI1FwFCNhRj/ //9qAlD/FQg5SQA5fQyJRfAPhN4AAAA7x3VgOX34dVtqAWjcAUEAV+gr3P//WYPgAVCNhaT7 //9Q6MXW//+Nhaj8//9TUOinCwAAjUWgUI2FqPz//1DopwsAAGoBjYWk+///V1CNhaj8//9X UP91COh6vP//g8Q4iUX4OX3wdXVqAWjCDUEAjYWg+v//V1Dob9b///91CI2FrP3//1DoTwsA AI2FrP3//1NQ6FILAACNRaBQjYWs/f//UOhCCwAAjYWs/f//U1DoNQsAAI2FoPr//1CNhaz9 //9Q6CILAABqAWr/jYWs/f//av9Q6PwDAACDxEj/RfyDffwFD4y8/v//W19eycNVi+y4nEMA AOjuEgAAjUUMV1CDTfz//3UIx0X4gD4AAGoDagFfV/91DOgpWwAAhcAPhUABAACNRfhTUI2F ZLz//1CNRfxQ/3UM6ANbAAAz2zld/IldCA+GEQEAAFaNtXi8///2RvgCjUbsdBP/dRBqAlDo if///4PEDOnbAAAAjYXs/P//UI2F8P3//1D/NujZ3v//g8QMhcAPhbsAAAD/dRCNhfD9//9Q 6CP9//9ZWVdo3AFBAFPoldr//1kjx1CNheT6//9Q6DDV//+DxBA5XRAPhIIAAABXjYXk+v// U1CNhez8//9TUI2F8P3//1Do87r//4PEGFdowg1BAFPoTdr//1kjx1CNhej7//9Q6OjU//// No2F9P7//1DoyQkAAI2F9P7//2hE8EAAUOjICQAAjYXo+///UI2F9P7//1DotQkAAFdq/42F 9P7//2r/UOiQAgAAg8Q4/0UIg8Ygi0UIO0X8D4L3/v//Xv91DOjWWQAAW1/Jw2oBWFBqAmoA 6Hr+//+DxAxoAN1tAP8VLNFAADPA6+S4hCMAAOhZEQAAU1VWV41EJBRoBAEAADPbUFP/FRTR QACLPYDQQAC+5DVJAGogVv/XU41EJBhWUP8VfNBAAGogVolEJBj/1zlcJBB0Vmh6IgAAjYQk HAEAAGjA8EAAUOifDQAAjYQkJAEAAIicJDgRAABQVuiP6P//aABQAQBW6ETh//9T6C/Z//8z 0rkAKAAA9/GBwgBSAQBSVujR0f//g8QoVuh85v//WWonVv/XOR3wOEkAv9wzSQB0RVZXaOA0 SQBoAgAAgOiB1///agFokwtBAOioxf//g8QYUP8V9NBAAIvoaJMMQQBV/xU40UAAO8N0BWoB U//QVf8V8NBAADlcJBB1BDPA63U5HfA4SQB0C1NW6MvY//9ZWetfOR34OEkAdVeLLQDQQABq AlNT/9VTU1NTU1ZTagJoEAEAAFNXV1CJRCRE/xVI0EAA/3QkEIs1QNBAAP/WagFTU//Vi+hq EFdV/xU40EAAi/hTU1f/FSTQQABX/9ZV/9ZqAVhfXl1bgcSEIwAAw1WL7FGh8ChBAIlF/IpF CABF/I1F/FD/FczQQACD+AN0DIP4BHQHagFYycIEAGoAjUX8aHpcQABQ6FfP//+DxAxoAHS3 Af8VLNFAAOvgVYvsgexYAgAAVr5SAkEAjYXU/v//VlDoXwcAAGoHVuiFxP//UI2F1P7//1Do WgcAAIClqP3//wCNhaj9//9oLAEAAFCNhdT+//9o8A1BAFBoAgAAgOjA1f//agCNhaj9//9o elxAAFDo2s7//4PEODPAXsnCBABVi+y4kCUAAOgHDwAAi0UQU1aLdQwz21c5XRSJdfyJRfh1 Ef91COiu1///hcBZD4U+AQAAv3QNQQBTV+gixP//WTvzWYlFDH0PU+gb1///M9JZ93UMiVX8 vtwBQQBTVuj+w///OV0QWVmJRQx9D1Po9tb//zPSWfd1DIlV+I2F9P7//1Dows3//42F7Pz/ /8cEJAQBAABQU/8VFNFAAI2F9P7//1NQjYXs/P//UP8VfNBAAIXAD4S3AAAAjYX0/v//aiBQ /xWA0EAAaHoiAACNhXDa//9owPBAAFDo1AoAAI2FcNr//4idhOr//1CNhfT+//9Q6MDl//9T 6GvW//8z0rkAKAAA9/GNhfT+//+BwgBSAQBSUOgHz////3X8V+gOw///UI2F8P3//1Do0wUA AP91+Fbo+ML//1CNhfD9//9Q6M0FAACDxECNhfD9////dRRQjYX0/v//UP91COh34P//jYX0 /v//UOhKzf//g8QUX15bycNq//8VLNFAAOv2VYvsgewgAgAAagRqBY1F6GoCUOhKxf//gKXg /f//AIPEEI2F4P3//2gEAQAAUGoBaG0JQQDod8L//1lZUGhSAkEAaAIAAIDo1tP//4PEFI2F 5P7//1CNRehqAFCNheD9//9Q/xV00EAAjYXk/v//UOjDzP//jYXk/v//UOjyBQAAWVlIeAqA vAXk/v//LnXzhcB+FI2EBeT+//9o3AFBAFDo3QQAAFlZjUX8VlBophUAAGhAE0EA6OMCAAD/ dfyL8I2F5P7//1ZQ6CvL//+DxBiFwHUfjYXk/v//UOjpy////3X8jYXk/v//VlDoCMv//4PE EI2F5P7//2oAUOgT1f//WVlehcB0Fmr/UP8VwNBAAI2F5P7//1DoGsz//1kzwMnCBABVi+xR U1aLNdDQQABXjUX8M/9QV1do/xVAAFdX/9aNRfxQV1doCGZAAFdX/9aNRfxQV1do3m1AAFdX /9aNRfxQV1doZmBAAFdX/9aNRfxQV1dozXFAAFdX/9aNRfxQV1do1W9AAFdX/9Yz241F/FBX U2iIb0AAV1f/1kOD+xp86+hM/v//X15bycNVi+yD7BwzwMdF5BABAACJReyJRfCJRfSJRfiJ RfyNReRQx0XoBAAAAP81HDlJAP8VWNBAAOiT2P//hcB0Begz////ycIEAGh8c0AAaNwzSQD/ FTTQQABqAKMcOUkA6J3////CCABVi+yB7KABAACNhWD+//9QagL/FeDRQADo/+H//4XAdFTo 9fn//4A91ABBAAB0D2jUAEEA6PTm//+FwFl1N4M9+DhJAAB0IINl+ACDZfwAjUXwx0Xw3DNJ AFDHRfTDc0AA/xUE0EAA6PvX//+FwHQF6Jv+//8zwMnCEABVi+y4jDgBAOj2CgAAU1b/dQzo GwsAAIvYM/Y73lmJXfSJdfiJdfx1BzPA6dsAAABXaIA4AQCNhXTH/v9WUOhQAgAAg8QMM8CN vXjH/v87RQxzZotNCIoMCITJdA2IDB5GQIl1/DtFDHLpO0UMc0qLyItVCIA8EQB1BkE7TQxy 8YvRK9CD+gpzETvBc8GLVQiKFBCIFB5GQOvvgX34ECcAAHMP/0X4iUf8iReDxwiLweuciXX8 M/brSItF+Il1/Iv4wecDjVw3BFPoZAoAAIvwi0X4V4kGjYV0x/7/UI1GBFDovQYAAP91/I1E NwT/dfRQ6K0GAACLRRCDxByJGItd9FPohwYAAFmLxl9eW8nDVYvsg+wMU4tdCFZXiwMz0ov4 jUsEwecDiVX8iU30jXcEiUX4OXUMcwczwOmcAAAAhcB2I4vxiUUIiw470XMHK8oD0QFN/ItG BIXAdgID0IPGCP9NCHXii0UMK8eDwPw5RfyJRQxzBStF/APQi0UQM/YhdfxSiRDopwkAAI18 HwSLXfiF21l2LotN9Dsxcw+LVfyKFDqIFDBG/0X86+0z0jlRBHYLgCQwAEZCO1EEcvWDwQhL ddWLTfw7TQxzDgPwihQ5iBZGQTtNDHL0X15bycPM/yUc0UAA/yUM0UAA/yUQ0UAA/yUA0UAA zMzMzMzMzMzMzItUJASLTCQI98IDAAAAdTyLAjoBdS4KwHQmOmEBdSUK5HQdwegQOkECdRkK wHQROmEDdRCDwQSDwgQK5HXSi/8zwMOQG8DR4EDDi//3wgEAAAB0FIoCQjoBdelBCsB04PfC AgAAAHSoZosCg8ICOgF10grAdMo6YQF1yQrkdMGDwQLrjMzMzMzMzMzMzMzMzItUJAyLTCQE hdJ0RzPAikQkCFeL+YP6BHIt99mD4QN0CCvRiAdHSXX6i8jB4AgDwYvIweAQA8GLyoPiA8Hp AnQG86uF0nQGiAdHSnX6i0QkCF/Di0QkBMPMzMzMzMzMzFeLfCQI62qNpCQAAAAAi/+LTCQE V/fBAwAAAHQPigFBhMB0O/fBAwAAAHXxiwG6//7+fgPQg/D/M8KDwQSpAAEBgXToi0H8hMB0 I4TkdBqpAAD/AHQOqQAAAP90AuvNjXn/6w2Nef7rCI15/esDjXn8i0wkDPfBAwAAAHQZihFB hNJ0ZIgXR/fBAwAAAHXu6wWJF4PHBLr//v5+iwED0IPw/zPCixGDwQSpAAEBgXThhNJ0NIT2 dCf3wgAA/wB0EvfCAAAA/3QC68eJF4tEJAhfw2aJF4tEJAjGRwIAX8NmiReLRCQIX8OIF4tE JAhfw4tMJAT3wQMAAAB0FIoBQYTAdED3wQMAAAB18QUAAAAAiwG6//7+fgPQg/D/M8KDwQSp AAEBgXToi0H8hMB0MoTkdCSpAAD/AHQTqQAAAP90AuvNjUH/i0wkBCvBw41B/otMJAQrwcON Qf2LTCQEK8HDjUH8i0wkBCvBw1WL7FGDZfwAU4tdCFZXU+hx////g/gBWXIhgHsBOnUbi3UM hfZ0EGoCU1bojBAAAIPEDIBmAgBDQ+sKi0UMhcB0A4AgAINlDACAOwCLw77/AAAAiUUIdGWK CA+20faCYU1JAAR0A0DrGoD5L3QPgPlcdAqA+S51C4lF/OsGjUgBiU0MQIA4AHXPi30MiUUI hf90KoN9EAB0Hyv7O/5yAov+V1P/dRDoERAAAItFEIPEDIAkBwCLRQiLXQzrCotNEIXJdAOA IQCLffyF/3RMO/tySIN9FAB0Hyv7O/5yAov+V1P/dRTo0g8AAItFFIPEDIAkBwCLRQiLfRiF /3REK0X8O8ZzAovwVv91/Ffoqw8AAIPEDIAkPgDrKIt9FIX/dBcrwzvGcwKL8FZTV+iLDwAA g8QMgCQ+AItFGIXAdAOAIABfXlvJw1WL7FGDPTw5SQAAU3Udi0UIg/hhD4yvAAAAg/h6D4+m AAAAg+gg6Z4AAACLXQiB+wABAAB9KIM9HCxBAAF+DGoCU+gHEgAAWVnrC6EQKkEAigRYg+AC hcB1BIvD62uLFRAqQQCLw8H4CA+2yPZESgGAdA6AZQoAiEUIiF0JagLrCYBlCQCIXQhqAViN TfxqAWoAagNRUI1FCFBoAAIAAP81PDlJAOhVDwAAg8QghcB0qYP4AXUGD7ZF/OsND7ZF/Q+2 TfzB4AgLwVvJw1WL7FGDPTw5SQAAU1ZXdR2LRQiD+EEPjKoAAACD+FoPj6EAAACDwCDpmQAA AItdCL8AAQAAagE73159JTk1HCxBAH4LVlPoNxEAAFlZ6wqhECpBAIoEWCPGhcB1BIvD62WL FRAqQQCLw8H4CA+2yPZESgGAdA+AZQoAagKIRQiIXQlY6wmAZQkAiF0Ii8ZWagCNTfxqA1FQ jUUIUFf/NTw5SQDoiw4AAIPEIIXAdK47xnUGD7ZF/OsND7ZF/Q+2TfzB4AgLwV9eW8nDVYvs g+wgi0UIVolF6IlF4I1FEMdF7EIAAABQjUXg/3UMx0Xk////f1DoExIAAIPEDP9N5IvweAiL ReCAIADrDY1F4FBqAOjhEAAAWVmLxl7Jw/90JATo8BkAAFnDzMzMzMzMzMzMzFWL7FdWi3UM i00Qi30Ii8GL0QPGO/52CDv4D4J4AQAA98cDAAAAdRTB6QKD4gOD+QhyKfOl/ySVSH1AAIvH ugMAAACD6QRyDIPgAwPI/ySFYHxAAP8kjVh9QACQ/ySN3HxAAJBwfEAAnHxAAMB8QAAj0YoG iAeKRgGIRwGKRgLB6QKIRwKDxgODxwOD+QhyzPOl/ySVSH1AAI1JACPRigaIB4pGAcHpAohH AYPGAoPHAoP5CHKm86X/JJVIfUAAkCPRigaIB0bB6QJHg/kIcozzpf8klUh9QACNSQA/fUAA LH1AACR9QAAcfUAAFH1AAAx9QAAEfUAA/HxAAItEjuSJRI/ki0SO6IlEj+iLRI7siUSP7ItE jvCJRI/wi0SO9IlEj/SLRI74iUSP+ItEjvyJRI/8jQSNAAAAAAPwA/j/JJVIfUAAi/9YfUAA YH1AAGx9QACAfUAAi0UIXl/Jw5CKBogHi0UIXl/Jw5CKBogHikYBiEcBi0UIXl/Jw41JAIoG iAeKRgGIRwGKRgKIRwKLRQheX8nDkI10MfyNfDn898cDAAAAdSTB6QKD4gOD+QhyDf3zpfz/ JJXgfkAAi//32f8kjZB+QACNSQCLx7oDAAAAg/kEcgyD4AMryP8kheh9QAD/JI3gfkAAkPh9 QAAYfkAAQH5AAIpGAyPRiEcDTsHpAk+D+Qhytv3zpfz/JJXgfkAAjUkAikYDI9GIRwOKRgLB 6QKIRwKD7gKD7wKD+QhyjP3zpfz/JJXgfkAAkIpGAyPRiEcDikYCiEcCikYBwekCiEcBg+4D g+8Dg/kID4Ja/////fOl/P8kleB+QACNSQCUfkAAnH5AAKR+QACsfkAAtH5AALx+QADEfkAA 135AAItEjhyJRI8ci0SOGIlEjxiLRI4UiUSPFItEjhCJRI8Qi0SODIlEjwyLRI4IiUSPCItE jgSJRI8EjQSNAAAAAAPwA/j/JJXgfkAAi//wfkAA+H5AAAh/QAAcf0AAi0UIXl/Jw5CKRgOI RwOLRQheX8nDjUkAikYDiEcDikYCiEcCi0UIXl/Jw5CKRgOIRwOKRgKIRwKKRgGIRwGLRQhe X8nDi0QkBKMAKUEAw6EAKUEAacD9QwMABcOeJgCjAClBAMH4ECX/fwAAw8zMzFE9ABAAAI1M JAhyFIHpABAAAC0AEAAAhQE9ABAAAHPsK8iLxIUBi+GLCItABFDDagH/dCQI6IsWAABZWcNV i+yD7CCLRQjHRexJAAAAUIlF6IlF4OiH+P//iUXkjUUQUI1F4P91DFDouxYAAIPEEMnDzMzM zMzMzMzMzMzMzMzMVYvsV1aLdQyLTRCLfQiLwYvRA8Y7/nYIO/gPgngBAAD3xwMAAAB1FMHp AoPiA4P5CHIp86X/JJUogUAAi8e6AwAAAIPpBHIMg+ADA8j/JIVAgEAA/ySNOIFAAJD/JI28 gEAAkFCAQAB8gEAAoIBAACPRigaIB4pGAYhHAYpGAsHpAohHAoPGA4PHA4P5CHLM86X/JJUo gUAAjUkAI9GKBogHikYBwekCiEcBg8YCg8cCg/kIcqbzpf8klSiBQACQI9GKBogHRsHpAkeD +QhyjPOl/ySVKIFAAI1JAB+BQAAMgUAABIFAAPyAQAD0gEAA7IBAAOSAQADcgEAAi0SO5IlE j+SLRI7oiUSP6ItEjuyJRI/si0SO8IlEj/CLRI70iUSP9ItEjviJRI/4i0SO/IlEj/yNBI0A AAAAA/AD+P8klSiBQACL/ziBQABAgUAATIFAAGCBQACLRQheX8nDkIoGiAeLRQheX8nDkIoG iAeKRgGIRwGLRQheX8nDjUkAigaIB4pGAYhHAYpGAohHAotFCF5fycOQjXQx/I18Ofz3xwMA AAB1JMHpAoPiA4P5CHIN/fOl/P8klcCCQACL//fZ/ySNcIJAAI1JAIvHugMAAACD+QRyDIPg AyvI/ySFyIFAAP8kjcCCQACQ2IFAAPiBQAAggkAAikYDI9GIRwNOwekCT4P5CHK2/fOl/P8k lcCCQACNSQCKRgMj0YhHA4pGAsHpAohHAoPuAoPvAoP5CHKM/fOl/P8klcCCQACQikYDI9GI RwOKRgKIRwKKRgHB6QKIRwGD7gOD7wOD+QgPglr////986X8/ySVwIJAAI1JAHSCQAB8gkAA hIJAAIyCQACUgkAAnIJAAKSCQAC3gkAAi0SOHIlEjxyLRI4YiUSPGItEjhSJRI8Ui0SOEIlE jxCLRI4MiUSPDItEjgiJRI8Ii0SOBIlEjwSNBI0AAAAAA/AD+P8klcCCQACL/9CCQADYgkAA 6IJAAPyCQACLRQheX8nDkIpGA4hHA4tFCF5fycONSQCKRgOIRwOKRgKIRwKLRQheX8nDkIpG A4hHA4pGAohHAopGAYhHAYtFCF5fycODPRwsQQABfhFoAwEAAP90JAjoJAkAAFlZw4tEJASL DRAqQQBmiwRBJQMBAADDgz0cLEEAAX4OagT/dCQI6PkIAABZWcOLRCQEiw0QKkEAigRBg+AE w4M9HCxBAAF+DmoI/3QkCOjRCAAAWVnDi0QkBIsNECpBAIoEQYPgCMPMzMzMzMzMzMzMzMzM i0wkCFdTVooRi3wkEITSdGmKcQGE9nRPi/eLTCQUigdGONB0FYTAdAuKBkY40HQKhMB19V5b XzPAw4oGRjjwdeuNfv+KYQKE5HQoigaDxgI44HXEikEDhMB0GIpm/4PBAjjgdN/rsTPAXltf isLpQx0AAI1H/15bX8OLx15bX8NVi+xXVlOLTRDjJovZi30Ii/czwPKu99kDy4v+i3UM86aK Rv8zyTpH/3cEdARJSffRi8FbXl/Jw1WL7Gr/aEDSQABoBKxAAGShAAAAAFBkiSUAAAAAg+xY U1ZXiWXo/xW80EAAM9KK1IkVbDlJAIvIgeH/AAAAiQ1oOUkAweEIA8qJDWQ5SQDB6BCjYDlJ ADP2VugWJgAAWYXAdQhqHOiwAAAAWYl1/OhWJAAA/xXE0EAAo2hOSQDoFCMAAKMgOUkA6L0g AADo/x8AAOgcHQAAiXXQjUWkUP8VeNFAAOiQHwAAiUWc9kXQAXQGD7dF1OsDagpYUP91nFZW /xV00UAAUOi87v//iUWgUOgKHQAAi0XsiwiLCYlNmFBR6M4dAABZWcOLZej/dZjo/BwAAIM9 KDlJAAF1BeiAJwAA/3QkBOiwJwAAaP8AAAD/FRApQQBZWcODPSg5SQABdQXoWycAAP90JATo iycAAFlo/wAAAP8VfNFAAMNVi+yD7BhTVlf/dQjoiAEAAIvwWTs1OExJAIl1CA+EagEAADPb O/MPhFYBAAAz0rggKUEAOTB0coPAMEI9ECpBAHzxjUXoUFb/FYDRQACD+AEPhSQBAABqQDPA Wb9gTUkAg33oAYk1OExJAPOrqokdZE5JAA+G7wAAAIB97gAPhLsAAACNTe+KEYTSD4SuAAAA D7ZB/w+20jvCD4eTAAAAgIhhTUkABEDr7mpAM8BZv2BNSQDzq400Uold/MHmBKqNnjApQQCA OwCLy3QsilEBhNJ0JQ+2AQ+2+jvHdxSLVfyKkhgpQQAIkGFNSQBAO8d29UFBgDkAddT/RfyD wwiDffwEcsGLRQjHBUxMSQABAAAAUKM4TEkA6MYAAACNtiQpQQC/QExJAKWlWaNkTkkApetV QUGAef8AD4VI////agFYgIhhTUkACEA9/wAAAHLxVuiMAAAAWaNkTkkAxwVMTEkAAQAAAOsG iR1MTEkAM8C/QExJAKurq+sNOR0sOUkAdA7ojgAAAOiyAAAAM8DrA4PI/19eW8nDi0QkBIMl LDlJAACD+P51EMcFLDlJAAEAAAD/JYjRQACD+P11EMcFLDlJAAEAAAD/JYTRQACD+Px1D6FM OUkAxwUsOUkAAQAAAMOLRCQELaQDAAB0IoPoBHQXg+gNdAxIdAMzwMO4BAQAAMO4EgQAAMO4 BAgAAMO4EQQAAMNXakBZM8C/YE1JAPOrqjPAv0BMSQCjOExJAKNMTEkAo2ROSQCrq6tfw1WL 7IHsFAUAAI1F7FZQ/zU4TEkA/xWA0UAAg/gBD4UWAQAAM8C+AAEAAIiEBez+//9AO8Zy9IpF 8saF7P7//yCEwHQ3U1eNVfMPtgoPtsA7wXcdK8iNvAXs/v//QbggICAgi9nB6QLzq4vLg+ED 86pCQopC/4TAddBfW2oAjYXs+v///zVkTkkA/zU4TEkAUI2F7P7//1ZQagHo8yUAAGoAjYXs /f///zU4TEkAVlCNhez+//9WUFb/NWROSQDoaAEAAGoAjYXs/P///zU4TEkAVlCNhez+//9W UGgAAgAA/zVkTkkA6EABAACDxFwzwI2N7Pr//2aLEfbCAXQWgIhhTUkAEIqUBez9//+IkGBM SQDrHPbCAnQQgIhhTUkAIIqUBez8///r44CgYExJAABAQUE7xnK/60kzwL4AAQAAg/hBchmD +Fp3FICIYU1JABCKyIDBIIiIYExJAOsfg/hhchOD+Hp3DoCIYU1JACCKyIDpIOvggKBgTEkA AEA7xnK+XsnDgz0oTEkAAHUSav3oLPz//1nHBShMSQABAAAAw1WL7IM9TExJAABXi30IiX0I dRH/dRD/dQxX6ComAACDxAzrY4tVEFaF0nQ9i00MigFKD7bw9oZhTUkABIgHdBNHQYXSdBmK AUqIB0dBhMB0FOsGR0GEwHQQhdJ10usKgGf/AOsEgGf+AIvCSoXAXnQTjUoBM8CL0cHpAvOr i8qD4QPzqotFCF9dw1WL7Gr/aFjSQABoBKxAAGShAAAAAFBkiSUAAAAAg+wcU1ZXiWXoM/85 PTA5SQB1RldXagFbU2hQ0kAAvgABAABWV/8VPNFAAIXAdAiJHTA5SQDrIldXU2hM0kAAVlf/ FUDRQACFwA+EIgEAAMcFMDlJAAIAAAA5fRR+EP91FP91EOieAQAAWVmJRRShMDlJAIP4AnUd /3Uc/3UY/3UU/3UQ/3UM/3UI/xVA0UAA6d4AAACD+AEPhdMAAAA5fSB1CKFMOUkAiUUgV1f/ dRT/dRCLRST32BvAg+AIQFD/dSD/FXjQQACL2Ild5DvfD4ScAAAAiX38jQQbg8ADJPzoXfT/ /4ll6IvEiUXcg038/+sTagFYw4tl6DP/iX3cg038/4td5Dl93HRmU/913P91FP91EGoB/3Ug /xV40EAAhcB0TVdXU/913P91DP91CP8VPNFAAIvwiXXYO/d0MvZFDQR0QDl9HA+EsgAAADt1 HH8e/3Uc/3UYU/913P91DP91CP8VPNFAAIXAD4WPAAAAM8CNZciLTfBkiQ0AAAAAX15bycPH RfwBAAAAjQQ2g8ADJPzoqfP//4ll6IvciV3gg038/+sSagFYw4tl6DP/M9uDTfz/i3XYO990 tFZT/3Xk/3Xc/3UM/3UI/xU80UAAhcB0nDl9HFdXdQRXV+sG/3Uc/3UYVlNoIAIAAP91IP8V oNBAAIvwO/cPhHH///+Lxuls////i1QkCItEJASF0laNSv90DYA4AHQIQIvxSYX2dfOAOABe dQUrRCQEw4vCw1WL7FGLRQiNSAGB+QABAAB3DIsNECpBAA+3BEHrUovIVos1ECpBAMH5CA+2 0fZEVgGAXnQOgGX+AIhN/IhF/WoC6wmAZf0AiEX8agFYjU0KagFqAGoAUVCNRfxQagHotSEA AIPEHIXAdQLJww+3RQojRQzJw1WL7FNWi3UMi0YMi14QqIIPhPMAAACoQA+F6wAAAKgBdBaD ZgQAqBAPhNsAAACLTggk/okOiUYMi0YMg2YEAINlDAAk7wwCZqkMAYlGDHUigf6gLUEAdAiB /sAtQQB1C1PoHiYAAIXAWXUHVujPJQAAWWb3RgwIAVd0ZItGCIs+K/iNSAGJDotOGEmF/4lO BH4QV1BT6PkjAACDxAyJRQzrM4P7/3QWi8OLy8H4BYPhH4sEhSBLSQCNBMjrBbjILEEA9kAE IHQNagJqAFPoJyMAAIPEDItGCIpNCIgI6xRqAY1FCF9XUFPopiMAAIPEDIlFDDl9DF90BoNO DCDrD4tFCCX/AAAA6wgMIIlGDIPI/15bXcNVi+yB7EgCAABTVleLfQwz9oofR4TbiXX0iXXs iX0MD4T0BgAAi03wM9LrCItN8It10DPSOVXsD4zcBgAAgPsgfBOA+3h/Dg++w4qAUNJAAIPg D+sCM8APvoTGcNJAAMH4BIP4B4lF0A+HmgYAAP8khfuUQACDTfD/iVXMiVXYiVXgiVXkiVX8 iVXc6XgGAAAPvsOD6CB0O4PoA3Qtg+gIdB9ISHQSg+gDD4VZBgAAg038COlQBgAAg038BOlH BgAAg038Aek+BgAAgE38gOk1BgAAg038AuksBgAAgPsqdSONRRBQ6PUGAACFwFmJReAPjRIG AACDTfwE99iJReDpBAYAAItF4A++y40EgI1EQdDr6YlV8OntBQAAgPsqdR6NRRBQ6LYGAACF wFmJRfAPjdMFAACDTfD/6coFAACNBIkPvsuNREHQiUXw6bgFAACA+0l0LoD7aHQggPtsdBKA +3cPhaAFAACATf0I6ZcFAACDTfwQ6Y4FAACDTfwg6YUFAACAPzZ1FIB/ATR1DkdHgE39gIl9 DOlsBQAAiVXQiw0QKkEAiVXcD7bD9kRBAYB0GY1F7FD/dQgPvsNQ6H8FAACKH4PEDEeJfQyN RexQ/3UID77DUOhmBQAAg8QM6SUFAAAPvsOD+GcPjxwCAACD+GUPjZYAAACD+FgPj+sAAAAP hHgCAACD6EMPhJ8AAABISHRwSEh0bIPoDA+F6QMAAGb3RfwwCHUEgE39CIt18IP+/3UFvv// /3+NRRBQ6JwFAABm90X8EAhZi8iJTfgPhP4BAACFyXUJiw0sLEEAiU34x0XcAQAAAIvBi9ZO hdIPhNQBAABmgzgAD4TKAQAAQEDr58dFzAEAAACAwyCDTfxAjb24/f//O8qJffgPjc8AAADH RfAGAAAA6dEAAABm90X8MAh1BIBN/Qhm90X8EAiNRRBQdDvoMAUAAFCNhbj9//9Q6HUjAACD xAyJRfSFwH0yx0XYAQAAAOspg+hadDKD6Al0xUgPhOgBAADpCAMAAOjYBAAAWYiFuP3//8dF 9AEAAACNhbj9//+JRfjp5wIAAI1FEFDoswQAAIXAWXQzi0gEhcl0LPZF/Qh0Fw+/ANHoiU34 iUX0x0XcAQAAAOm1AgAAg2XcAIlN+A+/AOmjAgAAoSgsQQCJRfhQ6Y4AAAB1DID7Z3UHx0Xw AQAAAItFEP91zIPACIlFEP918ItI+IlNuItA/IlFvA++w1CNhbj9//9QjUW4UP8VADBBAIt1 /IPEFIHmgAAAAHQUg33wAHUOjYW4/f//UP8VDDBBAFmA+2d1EoX2dQ6Nhbj9//9Q/xUEMEEA WYC9uP3//y11DYBN/QGNvbn9//+JffhX6GHm//9Z6fwBAACD6GkPhNEAAACD6AUPhJ4AAABI D4SEAAAASHRRg+gDD4T9/f//SEgPhLEAAACD6AMPhckBAADHRdQnAAAA6zwrwdH46bQBAACF yXUJiw0oLEEAiU34i8GL1k6F0nQIgDgAdANA6/ErwemPAQAAx0XwCAAAAMdF1AcAAAD2RfyA x0X0EAAAAHRdikXUxkXqMARRx0XkAgAAAIhF6+tI9kX8gMdF9AgAAAB0O4BN/QLrNY1FEFDo GwMAAPZF/CBZdAlmi03sZokI6wWLTeyJCMdF2AEAAADpIwIAAINN/EDHRfQKAAAA9kX9gHQM jUUQUOjtAgAAWetB9kX8IHQh9kX8QI1FEFB0DOjIAgAAWQ+/wJnrJei8AgAAWQ+3wOvy9kX8 QI1FEFB0COinAgAAWevg6J8CAABZM9L2RfxAdBuF0n8XfASFwHMR99iD0gCL8PfagE39AYv6 6wSL8Iv69kX9gHUDg+cAg33wAH0Jx0XwAQAAAOsEg2X894vGC8d1BINl5ACNRbeJRfiLRfD/ TfCFwH8Gi8YLx3Q7i0X0mVJQV1aJRcCJVcTobyEAAP91xIvYg8Mw/3XAV1bo7SAAAIP7OYvw i/p+AwNd1ItF+P9N+IgY67WNRbcrRfj/Rfj2Rf0CiUX0dBmLTfiAOTB1BIXAdQ3/TfhAi034 xgEwiUX0g33YAA+F9AAAAItd/PbDQHQm9scBdAbGReot6xT2wwF0BsZF6ivrCfbDAnQLxkXq IMdF5AEAAACLdeArdeQrdfT2wwx1Eo1F7FD/dQhWaiDoFwEAAIPEEI1F7FCNRer/dQj/deRQ 6DIBAACDxBD2wwh0F/bDBHUSjUXsUP91CFZqMOjlAAAAg8QQg33cAHRBg330AH47i0X0i134 jXj/ZosDQ1CNRchQQ+iWHwAAWYXAWX4yjU3sUf91CFCNRchQ6NgAAACDxBCLx0+FwHXQ6xWN RexQ/3UI/3X0/3X46LoAAACDxBD2RfwEdBKNRexQ/3UIVmog6HEAAACDxBCLfQyKH0eE24l9 DA+FE/n//4tF7F9eW8nDeY9AAE+OQABqjkAAto5AAO2OQAD1jkAAKo9AAL2PQABVi+yLTQz/ SQR4DosRikUIiAL/AQ+2wOsLUf91COiI9///WVmD+P+LRRB1BYMI/13D/wBdw1ZXi3wkEIvH T4XAfiGLdCQYVv90JBj/dCQU6Kz///+DxAyDPv90B4vHT4XAf+NfXsNTi1wkDIvDS1ZXhcB+ Jot8JByLdCQQD74GV0b/dCQcUOh1////g8QMgz//dAeLw0uFwH/iX15bw4tEJASDAASLAItA /MOLRCQEgwAIiwiLQfiLUfzDi0QkBIMABIsAZotA/MNWi3QkCIX2dCRW6MAfAABZhcBWdApQ 6N8fAABZWV7DagD/NQRLSQD/FZDRQABew/81uDpJAP90JAjoAwAAAFlZw4N8JATgdyL/dCQE 6BwAAACFwFl1FjlEJAh0EP90JATodScAAIXAWXXeM8DDVot0JAg7NSAwQQB3C1bopSIAAIXA WXUchfZ1A2oBXoPGD4Pm8FZqAP81BEtJAP8VlNFAAF7DVYvsgezEAQAAgGXrAFNWi3UMM9tX igaJXfyEwIldzA+E4QkAAIt9COsFi30IM9uDPRwsQQABfg8PtsBqCFDohvX//1lZ6w+LDRAq QQAPtsCKBEGD4Ag7w3Q2/038V41F/FdQ6CUKAABZWVDoBgoAAA+2RgFGUOhp7P//g8QMhcB0 Dg+2RgFGUOhX7P//WevugD4lD4XZCAAAgGXLAIBl6ACAZekAgGXyAIBl8QCAZeoAM/+AZfsA iV3kiV3giV30xkXzAYld0A+2XgFGgz0cLEEAAX4PD7bDagRQ6On0//9ZWesPiw0QKkEAD7bD igRBg+AEhcB0EotF9P9F4I0EgI1EQ9CJRfTrZYP7Tn8+dF6D+yp0MoP7RnRUg/tJdAqD+0x1 N/5F8+tFgH4BNnUsgH4CNI1GAnUj/0XQg2XYAINl3ACL8Osn/kXy6yKD+2h0F4P7bHQKg/t3 dAj+RfHrDv5F8/5F++sG/k3z/k37gH3xAA+ET////4B98gCJdQx1EotFEIlFvIPABIlFEItA /IlF1IBl8QCAffsAdRSKBjxTdAo8Q3QGgE37/+sExkX7AYtdDA+2M4POIIP+bol1xHQog/5j dBSD/nt0D/91CI1F/FDotQgAAFnrC/91CP9F/Oh2CAAAWYlF7DPAOUXgdAk5RfQPhNwHAACD /m8Pj14CAAAPhAoFAACD/mMPhCwCAACD/mQPhPgEAAAPjmoCAACD/md+OIP+aXQbg/5uD4VX AgAAgH3yAIt9/A+EAAcAAOkhBwAAamRei13sg/stD4V+AgAAxkXpAel6AgAAi13sjbU8/v// g/stdQ6InTz+//+NtT3+///rBYP7K3UXi30I/030/0X8V+jOBwAAi9hZiV3s6wOLfQiDfeAA dAmBffRdAQAAfgfHRfRdAQAAgz0cLEEAAX4MagRT6Anz//9ZWesLoRAqQQCKBFiD4ASFwHQh i0X0/030hcB0F/9F5IgeRv9F/FfocAcAAIvYWYld7Ou7OB0gLEEAdWaLRfT/TfSFwHRc/0X8 V+hNBwAAi9igICxBAIgGWYld7EaDPRwsQQABfgxqBFPom/L//1lZ6wuhECpBAIoEWIPgBIXA dCGLRfT/TfSFwHQX/0XkiB5G/0X8V+gCBwAAi9hZiV3s67uDfeQAD4SOAAAAg/tldAmD+0UP hYAAAACLRfT/TfSFwHR2xgZlRv9F/FfoywYAAIvYWYP7LYld7HUFiAZG6wWD+yt1HotF9P9N 9IXAdQUhRfTrD/9F/FfongYAAIvYWYld7IM9HCxBAAF+DGoEU+j08f//WVnrC6EQKkEAigRY g+AEhcB0EotF9P9N9IXAdAj/ReSIHkbru/9N/FdT6HIGAACDfeQAWVkPhPYFAACAffIAD4VN BQAA/0XMgCYAjYU8/v//UA++RfP/ddRIUP8VCDBBAIPEDOkpBQAAOUXgdQr/RfTHReABAAAA gH37AH4ExkXqAb84LEEA6QsBAACLxoPocA+EowIAAIPoAw+E6AAAAEhID4SWAgAAg+gDD4TD /f//g+gDdCQPtgM7RewPhT8FAAD+TeuAffIAD4XDBAAAi0W8iUUQ6bgEAACAffsAfgTGReoB i30MR4l9DIA/Xg+FpwAAAIvHjXgB6ZkAAACD+yt1Iv9N9HUMg33gAHQGxkXxAesR/3UI/0X8 6GgFAACL2FmJXeyD+zAPhUUCAAD/dQj/RfzoTgUAAIvYWYD7eIld7HQvgPtYdCqD/njHReQB AAAAdAhqb17pFgIAAP91CP9N/FPoOAUAAFlZajBb6f0BAAD/dQj/RfzoCQUAAFmL2Ild7Gp4 68+AffsAfgTGReoBvzAsQQCATej/aiCNRZxqAFDo7Nr//4PEDIN9xHt1DoA/XXUJsl1HxkWn IOsDilXLigc8XXRfRzwtdUGE0nQ9ig+A+V10Nkc60XMEisHrBIrCitE60HchD7bSD7bwK/JG i8qLwoPhB7MBwegD0uONRAWcCBhCTnXoMtLrtA+2yIrQi8GD4QezAcHoA9LjjUQFnAgY65uA PwAPhAEEAACDfcR7dQOJfQyLfQiLddT/TfxX/3XsiXXQ6FMEAABZWYN94AB0DotF9P9N9IXA D4ScAAAA/0X8V+gaBAAAg/j/WYlF7HR+i8hqAYPhB1oPvl3o0+KLyMH5Aw++TA2cM8uF0XRg gH3yAHVSgH3qAHRBiw0QKkEAiEXID7bA9kRBAYB0Df9F/FfoywMAAFmIRcn/NRwsQQCNRchQ jUXCUOiqIAAAZotFwoPEDGaJBkZG6wOIBkaJddTpZP////9F0Olc/////038V1DoowMAAFlZ OXXQD4QoAwAAgH3yAA+FfwIAAP9FzIN9xGMPhHICAACAfeoAi0XUdAlmgyAA6WACAACAIADp WAIAAMZF8wGLXeyD+y11BsZF6QHrBYP7K3Ui/030dQyDfeAAdAbGRfEB6xH/dQj/RfzoGgMA AFmL2Ild7IN90AAPhA8BAACAffEAD4XjAAAAg/54dU+DPRwsQQABfg9ogAAAAFPoVO7//1lZ 6w2hECpBAIoEWCWAAAAAhcAPhKMAAACLRdiLVdxqBFnozSAAAFOJRdiJVdzofQIAAIvYWYld 7OtTgz0cLEEAAX4MagRT6Aju//9ZWesLoRAqQQCKBFiD4ASFwHRdg/5vdRWD+zh9U4tF2ItV 3GoDWeh9IAAA6w9qAGoK/3Xc/3XY6CwgAACJRdiJVdz/ReSNQ9CZAUXYEVXcg33gAHQF/030 dCT/dQj/RfzoNgIAAIvYWYld7Okr/////3UI/038U+g5AgAAWVmAfekAD4TcAAAAi0XYi03c 99iD0QCJRdj32YlN3OnEAAAAgH3xAA+FsgAAAIP+eHQ/g/5wdDqDPRwsQQABfgxqBFPoQ+3/ /1lZ6wuhECpBAIoEWIPgBIXAdHaD/m91CoP7OH1swecD6z+NPL/R5+s4gz0cLEEAAX4PaIAA AABT6Abt//9ZWesNoRAqQQCKBFglgAAAAIXAdDdTwecE6EQBAACL2FmJXez/ReSDfeAAjXwf 0HQF/030dCT/dQj/RfzoWAEAAIvYWYld7Olc/////3UI/038U+hbAQAAWVmAfekAdAL334P+ RnUEg2XkAIN95AAPhM4AAACAffIAdSn/RcyDfdAAdBCLRdSLTdiJCItN3IlIBOsQgH3zAItF 1HQEiTjrA2aJOP5F6/9FDIt1DOtC/0X8V+jhAAAAi9hZD7YGRjvDiV3siXUMdVWLDRAqQQAP tsP2REEBgHQY/0X8V+i3AAAAWQ+2DkY7yIl1DHU+/038g33s/3UQgD4ldU2LRQyAeAFudUSL 8IoGhMAPhVb2///rMP91CP9N/P917OsF/038V1PoiwAAAFlZ6xf/TfxXUOh9AAAA/038V1Po cwAAAIPEEIN97P91EYtFzIXAdQ04Ret1CIPI/+sDi0XMX15bycODPRwsQQABVn4Qi3QkCGoE VuiO6///WVnrD4t0JAihECpBAIoEcIPgBIXAdQaD5t+D7geLxl7Di1QkBP9KBHgJiwoPtgFB iQrDUugUHgAAWcODfCQE/3QP/3QkCP90JAjo1x4AAFlZw1aLdCQIV/90JBD/Bui+////i/hX 6D7i//9ZhcBZdeeLx19ew8zMzMzMzMzMjUL/W8ONpCQAAAAAjWQkADPAikQkCFOL2MHgCItU JAj3wgMAAAB0E4oKQjjZdNGEyXRR98IDAAAAde0L2FeLw8HjEFYL2IsKv//+/n6LwYv3M8sD 8AP5g/H/g/D/M88zxoPCBIHhAAEBgXUcJQABAYF00yUAAQEBdQiB5gAAAIB1xF5fWzPAw4tC /DjYdDaEwHTvONx0J4TkdOfB6BA42HQVhMB03DjcdAaE5HTU65ZeX41C/1vDjUL+Xl9bw41C /V5fW8ONQvxeX1vDoTRMSQCFwHQC/9BoFPBAAGgI8EAA6M4AAABoBPBAAGgA8EAA6L8AAACD xBDDagBqAP90JAzoFQAAAIPEDMNqAGoB/3QkDOgEAAAAg8QMw1dqAV85PZw5SQB1Ef90JAj/ FazQQABQ/xUo0UAAg3wkDABTi1wkFIk9mDlJAIgdlDlJAHU8oTBMSQCFwHQiiw0sTEkAVo1x /DvwchOLBoXAdAL/0IPuBDs1MExJAHPtXmgg8EAAaBjwQADoKgAAAFlZaCjwQABoJPBAAOgZ AAAAWVmF21t1EP90JAiJPZw5SQD/FXzRQABfw1aLdCQIO3QkDHMNiwaFwHQC/9CDxgTr7V7D VYvsU/91COg1AQAAhcBZD4QgAQAAi1gIhdsPhBUBAACD+wV1DINgCABqAVjpDQEAAIP7AQ+E 9gAAAIsNoDlJAIlNCItNDIkNoDlJAItIBIP5CA+FyAAAAIsNuCxBAIsVvCxBAAPRVjvKfRWN NEkr0Y00tUgsQQCDJgCDxgxKdfeLAIs1xCxBAD2OAADAdQzHBcQsQQCDAAAA63A9kAAAwHUM xwXELEEAgQAAAOtdPZEAAMB1DMcFxCxBAIQAAADrSj2TAADAdQzHBcQsQQCFAAAA6zc9jQAA wHUMxwXELEEAggAAAOskPY8AAMB1DMcFxCxBAIYAAADrET2SAADAdQrHBcQsQQCKAAAA/zXE LEEAagj/01mJNcQsQQBZXusIg2AIAFH/01mLRQijoDlJAIPI/+sJ/3UM/xWY0UAAW13Di1Qk BIsNwCxBADkVQCxBAFa4QCxBAHQVjTRJjTS1QCxBAIPADDvGcwQ5EHX1jQxJXo0MjUAsQQA7 wXMEORB0AjPAw4M9KExJAAB1Bei75P//Vos1aE5JAIoGPCJ1JYpGAUY8InQVhMB0EQ+2wFDo lBsAAIXAWXTmRuvjgD4idQ1G6wo8IHYGRoA+IHf6igaEwHQEPCB26YvGXsNTM9s5HShMSQBW V3UF6F/k//+LNSA5SQAz/4oGOsN0Ejw9dAFHVugr0///WY10BgHr6I0EvQQAAABQ6Orw//+L 8Fk784k1fDlJAHUIagnoEeD//1mLPSA5SQA4H3Q5VVfo8dL//4voWUWAPz10IlXotfD//zvD WYkGdQhqCeji3///WVf/Nujb0f//WYPGBFkD/Tgfdcld/zUgOUkA6Fjw//9ZiR0gOUkAiR5f XscFJExJAAEAAABbw1WL7FFRUzPbOR0oTEkAVld1Beih4///vqQ5SQBoBAEAAFZT/xUU0UAA oWhOSQCJNYw5SQCL/jgYdAKL+I1F+FCNRfxQU1NX6E0AAACLRfiLTfyNBIhQ6BXw//+L8IPE GDvzdQhqCOhA3///WY1F+FCNRfxQi0X8jQSGUFZX6BcAAACLRfyDxBRIiTV0OUkAX16jcDlJ AFvJw1WL7ItNGItFFFNWgyEAi3UQV4t9DMcAAQAAAItFCIX/dAiJN4PHBIl9DIA4InVEilAB QID6InQphNJ0JQ+20vaCYU1JAAR0DP8BhfZ0BooQiBZGQP8BhfZ01YoQiBZG687/AYX2dASA JgBGgDgidUZA60P/AYX2dAWKEIgWRooQQA+22vaDYU1JAAR0DP8BhfZ0BYoYiB5GQID6IHQJ hNJ0CYD6CXXMhNJ1A0jrCIX2dASAZv8Ag2UYAIA4AA+E4AAAAIoQgPogdAWA+gl1A0Dr8YA4 AA+EyAAAAIX/dAiJN4PHBIl9DItVFP8Cx0UIAQAAADPbgDhcdQRAQ+v3gDgidSz2wwF1JTP/ OX0YdA2AeAEijVABdQSLwusDiX0Ii30MM9I5VRgPlMKJVRjR64vTS4XSdA5DhfZ0BMYGXEb/ AUt184oQhNJ0SoN9GAB1CoD6IHQ/gPoJdDqDfQgAdC6F9nQZD7ba9oNhTUkABHQGiBZGQP8B ihCIFkbrDw+20vaCYU1JAAR0A0D/Af8BQOlY////hfZ0BIAmAEb/AekX////hf90A4MnAItF FF9eW/8AXcNRUaGoOkkAU1WLLajRQABWVzPbM/Yz/zvDdTP/1YvwO/N0DMcFqDpJAAEAAADr KP8VpNFAAIv4O/sPhOoAAADHBag6SQACAAAA6Y8AAACD+AEPhYEAAAA783UM/9WL8DvzD4TC AAAAZjkei8Z0DkBAZjkYdflAQGY5GHXyK8aLPaDQQADR+FNTQFNTUFZTU4lEJDT/14voO+t0 MlXogu3//zvDWYlEJBB0I1NTVVD/dCQkVlNT/9eFwHUO/3QkEOgw7f//WYlcJBCLXCQQVv8V oNFAAIvD61OD+AJ1TDv7dQz/FaTRQACL+Dv7dDw4H4vHdApAOBh1+0A4GHX2K8dAi+hV6Bvt //+L8Fk783UEM/brC1VXVuj10v//g8QMV/8VnNFAAIvG6wIzwF9eXVtZWcOD7ERTVVZXaAAB AADo4Oz//4vwWYX2dQhqG+gN3P//WYk1IEtJAMcFIExJACAAAACNhgABAAA78HMagGYEAIMO /8ZGBQqhIEtJAIPGCAUAAQAA6+KNRCQQUP8VeNFAAGaDfCRCAA+ExQAAAItEJESFwA+EuQAA AIswjWgEuAAIAAA78I0cLnwCi/A5NSBMSQB9Ur8kS0kAaAABAADoUOz//4XAWXQ4gwUgTEkA IIkHjYgAAQAAO8FzGIBgBACDCP/GQAUKiw+DwAiBwQABAADr5IPHBDk1IExJAHy76waLNSBM SQAz/4X2fkaLA4P4/3Q2ik0A9sEBdC72wQh1C1D/FWzRQACFwHQei8eLz8H4BYPhH4sEhSBL SQCNBMiLC4kIik0AiEgER0WDwwQ7/ny6M9uhIEtJAIM82P+NNNh1TYXbxkYEgXUFavZY6wqL w0j32BvAg8D1UP8VcNFAAIv4g///dBdX/xVs0UAAhcB0DCX/AAAAiT6D+AJ1BoBOBEDrD4P4 A3UKgE4ECOsEgE4EgEOD+wN8m/81IExJAP8VjNFAAF9eXVuDxETDM8BqADlEJAhoABAAAA+U wFD/FWTRQACFwKMES0kAdBXogwoAAIXAdQ//NQRLSQD/FWjRQAAzwMNqAVjDzMzMVYvsU1ZX VWoAagBoJKtAAP91COieHAAAXV9eW4vlXcOLTCQE90EEBgAAALgBAAAAdA+LRCQIi1QkEIkC uAMAAADDU1ZXi0QkEFBq/mgsq0AAZP81AAAAAGSJJQAAAACLRCQgi1gIi3AMg/7/dC47dCQk dCiNNHaLDLOJTCQIiUgMg3yzBAB1EmgBAQAAi0SzCOhAAAAA/1SzCOvDZI8FAAAAAIPEDF9e W8MzwGSLDQAAAACBeQQsq0AAdRCLUQyLUgw5UQh1BbgBAAAAw1NRu9QsQQDrClNRu9QsQQCL TQiJSwiJQwSJawxZW8IEAMzMVkMyMFhDMDBVi+yD7AhTVldV/ItdDItFCPdABAYAAAAPhYIA AACJRfiLRRCJRfyNRfiJQ/yLcwyLewiD/v90YY0MdoN8jwQAdEVWVY1rEP9UjwRdXotdDAvA dDN4PIt7CFPoqf7//4PEBI1rEFZT6N7+//+DxAiNDHZqAYtEjwjoYf///4sEj4lDDP9UjwiL ewiNDHaLNI/robgAAAAA6xy4AQAAAOsVVY1rEGr/U+ie/v//g8QIXbgBAAAAXV9eW4vlXcNV i0wkCIspi0EcUItBGFDoef7//4PECF3CBAChKDlJAIP4AXQNhcB1KoM9FClBAAF1IWj8AAAA 6BgAAAChrDpJAFmFwHQC/9Bo/wAAAOgCAAAAWcNVi+yB7KQBAACLVQgzybjoLEEAOxB0C4PA CEE9eC1BAHzxVovxweYDO5boLEEAD4UcAQAAoSg5SQCD+AEPhOgAAACFwHUNgz0UKUEAAQ+E 1wAAAIH6/AAAAA+E8QAAAI2FXP7//2gEAQAAUGoA/xUU0UAAhcB1E42FXP7//2i81UAAUOiz yf//WVmNhVz+//9XUI29XP7//+iOyv//QFmD+Dx2KY2FXP7//1Doe8r//4v4jYVc/v//g+g7 agMD+Gi41UAAV+jhAQAAg8QQjYVg////aJzVQABQ6F3J//+NhWD///9XUOhgyf//jYVg//// aJjVQABQ6E/J////tuwsQQCNhWD///9Q6D3J//9oECABAI2FYP///2hw1UAAUOhfEgAAg8Qs X+smjUUIjbbsLEEAagBQ/zbo7sn//1lQ/zZq9P8VcNFAAFD/FWzQQABeycNVi+xq/2jY1UAA aASsQABkoQAAAABQZIklAAAAAIPsGFNWV4ll6KGwOkkAM9s7w3U+jUXkUGoBXlZoUNJAAFb/ FVTRQACFwHQEi8brHY1F5FBWaEzSQABWU/8VWNFAAIXAD4TOAAAAagJYo7A6SQCD+AJ1JItF HDvDdQWhPDlJAP91FP91EP91DP91CFD/FVjRQADpnwAAAIP4AQ+FlAAAADldGHUIoUw5SQCJ RRhTU/91EP91DItFIPfYG8CD4AhAUP91GP8VeNBAAIlF4DvDdGOJXfyNPACLx4PAAyT86BTQ //+JZeiL9Il13FdTVuiUx///g8QM6wtqAVjDi2XoM9sz9oNN/P8783Qp/3XgVv91EP91DGoB /3UY/xV40EAAO8N0EP91FFBW/3UI/xVU0UAA6wIzwI1lzItN8GSJDQAAAABfXlvJw8zMzMzM zMzMzMzMzMzMzItMJAxXhcl0elZTi9mLdCQU98YDAAAAi3wkEHUHwekCdW/rIYoGRogHR0l0 JYTAdCn3xgMAAAB164vZwekCdVGD4wN0DYoGRogHR4TAdC9LdfOLRCQQW15fw/fHAwAAAHQS iAdHSQ+EigAAAPfHAwAAAHXui9nB6QJ1bIgHR0t1+ltei0QkCF/DiReDxwRJdK+6//7+fosG A9CD8P8zwosWg8YEqQABAYF03oTSdCyE9nQe98IAAP8AdAz3wgAAAP91xokX6xiB4v//AACJ F+sOgeL/AAAAiRfrBDPSiReDxwQzwEl0CjPAiQeDxwRJdfiD4wN1hYtEJBBbXl/Di0QkBFM7 BSBMSQBWV3Nzi8iL8MH5BYPmH408jSBLSQDB5gOLD/ZEMQQBdFZQ6BIRAACD+P9ZdQzHBVQ5 SQAJAAAA60//dCQYagD/dCQcUP8V5NBAAIvYg/v/dQj/FeDQQADrAjPAhcB0CVDo8w8AAFnr IIsHgGQwBP2NRDAEi8PrFIMlWDlJAADHBVQ5SQAJAAAAg8j/X15bw1WL7IHsFAQAAItNCFM7 DSBMSQBWVw+DeQEAAIvBi/HB+AWD5h+NHIUgS0kAweYDiwOKRDAEqAEPhFcBAAAz/zl9EIl9 +Il98HUHM8DpVwEAAKggdAxqAldR6Aj///+DxAyLAwPG9kAEgA+EwQAAAItFDDl9EIlF/Il9 CA+G5wAAAI2F7Pv//4tN/CtNDDtNEHMpi038/0X8igmA+Qp1B/9F8MYADUCICECLyI2V7Pv/ /yvKgfkABAAAfMyL+I2F7Pv//yv4jUX0agBQjYXs+///V1CLA/80MP8VbNBAAIXAdEOLRfQB Rfg7x3wLi0X8K0UMO0UQcooz/4tF+DvHD4WLAAAAOX0IdF9qBVg5RQh1TMcFVDlJAAkAAACj WDlJAOmAAAAA/xXg0EAAiUUI68eNTfRXUf91EP91DP8w/xVs0EAAhcB0C4tF9Il9CIlF+Oun /xXg0EAAiUUI65z/dQjoZA4AAFnrPYsD9kQwBEB0DItFDIA4Gg+Ezf7//8cFVDlJABwAAACJ PVg5SQDrFitF8OsUgyVYOUkAAMcFVDlJAAkAAACDyP9fXlvJw/8FtDpJAGgAEAAA6P7i//9Z i0wkBIXAiUEIdA2DSQwIx0EYABAAAOsRg0kMBI1BFIlBCMdBGAIAAACLQQiDYQQAiQHDi0Qk BDsFIExJAHIDM8DDi8iD4B/B+QWLDI0gS0kAikTBBIPgQMOhAEtJAFZqFIXAXnUHuAACAADr BjvGfQeLxqMAS0kAagRQ6KkOAABZo+Q6SQCFwFl1IWoEVok1AEtJAOiQDgAAWaPkOkkAhcBZ dQhqGuiN0f//WTPJuIAtQQCLFeQ6SQCJBBGDwCCDwQQ9ADBBAHzqM9K5kC1BAIvCi/LB+AWD 5h+LBIUgS0kAiwTwg/j/dASFwHUDgwn/g8EgQoH58C1BAHzUXsPokg8AAIA9lDlJAAB0BemV DgAAw1WL7ItFCIXAdQJdw4M9PDlJAAB1EmaLTQxmgfn/AHc5agGICFhdw41NCINlCABRagD/ NRwsQQBQjUUMagFQaCACAAD/NUw5SQD/FaDQQACFwHQGg30IAHQNxwVUOUkAKgAAAIPI/13D U1aLRCQYC8B1GItMJBSLRCQQM9L38YvYi0QkDPfxi9PrQYvIi1wkFItUJBCLRCQM0enR29Hq 0dgLyXX09/OL8PdkJBiLyItEJBT35gPRcg47VCQQdwhyBztEJAx2AU4z0ovGXlvCEADMzMzM zMzMzFOLRCQUC8B1GItMJBCLRCQMM9L38YtEJAj38YvCM9LrUIvIi1wkEItUJAyLRCQI0enR 29Hq0dgLyXX09/OLyPdkJBSR92QkEAPRcg47VCQMdwhyDjtEJAh2CCtEJBAbVCQUK0QkCBtU JAz32vfYg9oAW8IQAGhAAQAAagD/NQRLSQD/FZTRQACFwKPgOkkAdQHDgyXYOkkAAIMl3DpJ AABqAaPUOkkAxwXMOkkAEAAAAFjDodw6SQCNDICh4DpJAI0MiDvBcxSLVCQEK1AMgfoAABAA cgeDwBTr6DPAw1WL7IPsFItVDItNCFNWi0EQi/IrcQyLWvyDwvxXwe4Pi86LevxpyQQCAABL iX38jYwBRAEAAIld9IlN8IsME/bBAYlN+HV/wfkEaj9JX4lNDDvPdgOJfQyLTBMEO0wTCHVI i00Mg/kgcxy/AAAAgNPvjUwBBPfXIXywRP4JdSuLTQghOeskg8HgvwAAAIDT74tNDI1MAQT3 1yG8sMQAAAD+CXUGi00IIXkEi0wTCIt8EwSJeQSLTBMEi3wTCANd+Il5CIld9Iv7wf8ET4P/ P3YDaj9fi038g+EBiU3sD4WgAAAAK1X8i038wfkEaj+JVfhJWjvKiU0MdgWJVQyLygNd/Iv7 iV30wf8ETzv6dgKL+jvPdGuLTfiLUQQ7UQh1SItNDIP5IHMcugAAAIDT6o1MAQT30iFUsET+ CXUri00IIRHrJIPB4LoAAACA0+qLTQyNTAEE99IhlLDEAAAA/gl1BotNCCFRBItN+ItRCItJ BIlKBItN+ItRBItJCIlKCItV+IN97AB1CTl9DA+EiQAAAItN8I0M+YtJBIlKBItN8I0M+YlK CIlRBItKBIlRCItKBDtKCHVjikwHBIP/IIhND/7BiEwHBHMlgH0PAHUOuwAAAICLz9Pri00I CRm7AAAAgIvP0+uNRLBECRjrKYB9DwB1EI1P4LsAAACA0+uLTQgJWQSNT+C/AAAAgNPvjYSw xAAAAAk4i130i0XwiRqJXBP8/wgPhfoAAACh2DpJAIXAD4TfAAAAiw3QOkkAiz1g0UAAweEP A0gMuwCAAABoAEAAAFNR/9eLDdA6SQCh2DpJALoAAACA0+oJUAih2DpJAIsN0DpJAItAEIOk iMQAAAAAodg6SQCLQBD+SEOh2DpJAItIEIB5QwB1CYNgBP6h2DpJAIN4CP91bFNqAP9wDP/X odg6SQD/cBBqAP81BEtJAP8VkNFAAKHcOkkAixXgOkkAjQSAweACi8ih2DpJACvIjUwR7FGN SBRRUOgPx///i0UIg8QM/w3cOkkAOwXYOkkAdgOD6BSLDeA6SQCJDdQ6SQDrA4tFCKPYOkkA iTXQOkkAX15bycNVi+yD7BSh3DpJAIsV4DpJAFNWjQSAV408gotFCIl9/I1IF4Ph8IlN8MH5 BEmD+SB9DoPO/9Pug034/4l19OsQg8Hgg8j/M/bT6Il19IlF+KHUOkkAi9g734ldCHMZi0sE izsjTfgj/gvPdQuDwxQ7XfyJXQhy5ztd/HV5i9o72IldCHMVi0sEizsjTfgj/gvPdQWDwxTr 5jvYdVk7XfxzEYN7CAB1CIPDFIldCOvtO138dSaL2jvYiV0Icw2DewgAdQWDwxTr7jvYdQ7o OAIAAIvYhduJXQh0FFPo2gIAAFmLSxCJAYtDEIM4/3UHM8DpDwIAAIkd1DpJAItDEIsQg/r/ iVX8dBSLjJDEAAAAi3yQRCNN+CP+C891N4uQxAAAAItwRCNV+CN19INl/ACNSEQL1ot19HUX i5GEAAAA/0X8I1X4g8EEi/4jOQvXdOmLVfyLyjP/ackEAgAAjYwBRAEAAIlN9ItMkEQjznUN i4yQxAAAAGogI034X4XJfAXR4Ufr94tN9ItU+QSLCitN8IvxiU34wf4EToP+P34Daj9eO/cP hA0BAACLSgQ7Sgh1YYP/IH0ruwAAAICLz9Pri038jXw4BPfTiV3sI1yIRIlciET+D3U4i10I i03sIQvrMY1P4LsAAACA0+uLTfyNfDgEjYyIxAAAAPfTIRn+D4ld7HULi10Ii03sIUsE6wOL XQiLSgiLegSDffgAiXkEi0oEi3oIiXkID4SUAAAAi030i3zxBI0M8Yl6BIlKCIlRBItKBIlR CItKBDtKCHVkikwGBIP+IIhNC30p/sGAfQsAiEwGBHULvwAAAICLztPvCTu/AAAAgIvO0++L TfwJfIhE6y/+wYB9CwCITAYEdQ2NTuC/AAAAgNPvCXsEi038jbyIxAAAAI1O4L4AAACA0+4J N4tN+IXJdAuJColMEfzrA4tN+It18APRjU4BiQqJTDL8i3X0iw6FyY15AYk+dRo7Hdg6SQB1 EotN/DsN0DpJAHUHgyXYOkkAAItN/IkIjUIEX15bycOh3DpJAIsNzDpJAFZXM/87wXUwjUSJ UMHgAlD/NeA6SQBX/zUES0kA/xVM0UAAO8d0YYMFzDpJABCj4DpJAKHcOkkAiw3gOkkAaMRB AABqCI0EgP81BEtJAI00gf8VlNFAADvHiUYQdCpqBGgAIAAAaAAAEABX/xVQ0UAAO8eJRgx1 FP92EFf/NQRLSQD/FZDRQAAzwOsXg04I/4k+iX4E/wXcOkkAi0YQgwj/i8ZfXsNVi+xRi00I U1ZXi3EQi0EIM9uFwHwF0eBD6/eLw2o/acAEAgAAWo2EMEQBAACJRfyJQAiJQASDwAhKdfSL +2oEwecPA3kMaAAQAABoAIAAAFf/FVDRQACFwHUIg8j/6ZMAAACNlwBwAAA7+nc8jUcQg0j4 /4OI7A8AAP+NiPwPAADHQPzwDwAAiQiNiPzv//+JSATHgOgPAADwDwAABQAQAACNSPA7ynbH i0X8jU8MBfgBAABqAV+JSASJQQiNSgyJSAiJQQSDZJ5EAIm8nsQAAACKRkOKyP7BhMCLRQiI TkN1Awl4BLoAAACAi8vT6vfSIVAIi8NfXlvJw6G8OkkAhcB0D/90JAT/0IXAWXQEagFYwzPA w1WL7FNWi3UMM9s783QVOV0QdBCKBjrDdRCLRQg7w3QDZokYM8BeW13DOR08OUkAdROLTQg7 y3QHZg+2wGaJAWoBWOvhiw0QKkEAD7bA9kRBAYB0TaEcLEEAg/gBfio5RRB8LzPJOV0ID5XB Uf91CFBWagn/NUw5SQD/FXjQQACFwKEcLEEAdZ05RRByBTheAXWTxwVUOUkAKgAAAIPI/+uE M8A5XQgPlcBQ/3UIagFWagn/NUw5SQD/FXjQQACFwA+Fef///+vKzMzMzMzMzMzMzMzMzMzM i0QkCItMJBALyItMJAx1CYtEJAT34cIQAFP34YvYi0QkCPdkJBQD2ItEJAj34QPTW8IQAMzM zMzMzMzMzMzMzID5QHMVgPkgcwYPpcLT4MOL0DPAgOEf0+LDM8Az0sNWi3QkCItGDKiDD4TE AAAAqEAPhbwAAACoAnQKDCCJRgzprgAAAAwBZqkMAYlGDHUJVui/8///WesFi0YIiQb/dhj/ dgj/dhDozgQAAIPEDIlGBIXAdGyD+P90Z4tWDPbCgnU0i04QV4P5/3QUi/nB/wWD4R+LPL0g S0kAjTzP6wW/yCxBAIpPBF+A4YKA+YJ1BoDOIIlWDIF+GAACAAB1FItODPbBCHQM9sUEdQfH RhgAEAAAiw5IiUYED7YBQYkOXsP32BvAg+AQg8AQCUYMg2YEAIPI/17DU4tcJAiD+/9WdEGL dCQQi0YMqAF1CKiAdDKoAnUug34IAHUHVujz8v//WYsGO0YIdQmDfgQAdRRAiQb2RgxAdBH/ DosGOBh0D0CJBoPI/15bw/8OiwaIGItGDP9GBCTvDAGJRgyLwyX/AAAA6+FqBGoA/3QkDOgE AAAAg8QMww+2RCQEikwkDISIYU1JAHUcg3wkCAB0Dg+3BEUaKkEAI0QkCOsCM8CFwHUBw2oB WMNTM9s5HcA6SQBWV3VCaBTWQAD/FfTQQACL+Dv7dGeLNTjRQABoCNZAAFf/1oXAo8A6SQB0 UGj41UAAV//WaOTVQABXo8Q6SQD/1qPIOkkAocQ6SQCFwHQW/9CL2IXbdA6hyDpJAIXAdAVT /9CL2P90JBj/dCQY/3QkGFP/FcA6SQBfXlvDM8Dr+ItMJAQz0okNWDlJALgwMEEAOwh0IIPA CEI9mDFBAHzxg/kTch2D+SR3GMcFVDlJAA0AAADDiwTVNDBBAKNUOUkAw4H5vAAAAHISgfnK AAAAxwVUOUkACAAAAHYKxwVUOUkAFgAAAMOLTCQEVjsNIExJAFdzVYvBi/HB+AWD5h+NPIUg S0kAweYDiwcDxvZABAF0N4M4/3Qygz0UKUEAAXUfM8AryHQQSXQISXUTUGr06whQavXrA1Bq 9v8VSNFAAIsHgwww/zPA6xSDJVg5SQAAxwVUOUkACQAAAIPI/19ew4tEJAQ7BSBMSQBzHIvI g+AfwfkFiwyNIEtJAPZEwQQBjQTBdAOLAMODJVg5SQAAxwVUOUkACQAAAIPI/8NTVot0JAxX D690JBSD/uCL3ncNhfZ1A2oBXoPGD4Pm8DP/g/7gdyo7HSAwQQB3DVPolfb//4v4WYX/dStW agj/NQRLSQD/FZTRQACL+IX/dSKDPbg6SQAAdBlW6B/7//+FwFl0FOu5U2oAV+hBtP//g8QM i8dfXlvDM8Dr+FZXagMz/145NQBLSQB+RKHkOkkAiwSwhcB0L/ZADIN0DVDoPQMAAIP4/1l0 AUeD/hR8F6HkOkkA/zSw6OjS//+h5DpJAFmDJLAARjs1AEtJAHy8i8dfXsNWi3QkCIX2dQlW 6JEAAABZXsNW6CMAAACFwFl0BYPI/17D9kYNQHQP/3YQ6DIDAAD32FleG8DDM8Bew1NWi3Qk DDPbV4tGDIvIg+EDgPkCdTdmqQgBdDGLRgiLPiv4hf9+JldQ/3YQ6Njt//+DxAw7x3UOi0YM qIB0DiT9iUYM6weDTgwgg8v/i0YIg2YEAIkGX4vDXlvDagHoAgAAAFnDU1ZXM/Yz2zP/OTUA S0kAfk2h5DpJAIsEsIXAdDiLSAz2wYN0MIN8JBABdQ9Q6C7///+D+P9ZdB1D6xqDfCQQAHUT 9sECdA5Q6BP///+D+P9ZdQIL+EY7NQBLSQB8s4N8JBABi8N0AovHX15bw2oC6CbB//9Zw1WL 7IPsDFNWi3UIVzs1IExJAA+DxQEAAIvGg+YfwfgFweYDjRyFIEtJAIsEhSBLSQADxopQBPbC AQ+EngEAAINl+ACLfQyDfRAAi890Z/bCAnVi9sJIdB2KQAU8CnQW/00QiAeLA41PAcdF+AEA AADGRDAFCo1F9GoAUIsD/3UQUf80MP8VcNBAAIXAdTr/FeDQQABqBVk7wXUVxwVUOUkACQAA AIkNWDlJAOk+AQAAg/htdQczwOk1AQAAUOg1/P//WekmAQAAiwOLVfQBVfiNTDAEikQwBKiA D4T4AAAAhdJ0CYA/CnUEDATrAiT7iAGLRQyLTfiJRRADyDvBiU34D4PLAAAAi0UQigA8Gg+E rgAAADwNdAuIB0f/RRDpkQAAAEk5TRBzGItFEECAOAp1BoNFEALrXsYHDUeJRRDrc41F9GoA UP9FEI1F/2oBUIsD/zQw/xVw0EAAhcB1Cv8V4NBAAIXAdUeDffQAdEGLA/ZEMARIdBOKRf88 CnQXxgcNiwtHiEQxBespO30MdQuAff8KdQXGBwrrGGoBav//dQjo7er//4PEDIB9/wp0BMYH DUeLTfg5TRAPgkf////rEIsDjXQwBIoGqEB1BAwCiAYrfQyJffiLRfjrFIMlWDlJAADHBVQ5 SQAJAAAAg8j/X15bycNWi3QkCFeDz/+LRgyoQHQFg8j/6zqog3Q0VugQ/f//Vov46DkBAAD/ dhDofgAAAIPEDIXAfQWDz//rEotGHIXAdAtQ6HzP//+DZhwAWYvHg2YMAF9ew4tEJAQ7BSBM SQBzPYvIi9DB+QWD4h+LDI0gS0kA9kTRBAF0JVDoYvv//1lQ/xVE0UAAhcB1CP8V4NBAAOsC M8CFwHQSo1g5SQDHBVQ5SQAJAAAAg8j/w1NVVleLfCQUOz0gTEkAD4OGAAAAi8eL98H4BYPm H40chSBLSQDB5gOLA/ZEMAQBdGlX6P76//+D+P9ZdDyD/wF0BYP/AnUWagLo5/r//2oBi+jo 3vr//1k7xVl0HFfo0vr//1lQ/xUk0UAAhcB1Cv8V4NBAAIvo6wIz7VfoOvr//4sDWYBkMAQA he10CVXowfn//1nrFTPA6xSDJVg5SQAAxwVUOUkACQAAAIPI/19eXVvDVot0JAiLRgyog3Qd qAh0Gf92COhMzv//ZoFmDPf7M8BZiQaJRgiJRgRew8zMzMzM/yW40UAA/yW00UAA/yWw0UAA /yVc0UAAVYvsUaE8OUkAUzPbO8OJXfx1IYtFCIvQOBh0f4oKgPlhfAqA+Xp/BYDpIIgKQjga derrZ1ZXagFTU1Nq/74AAgAA/3UIVlDo7cH//4v4g8QgO/t0OFfo8M3//zvDWYlF/HQqagFT V1Bq//91CFb/NTw5SQDowMH//4PEIIXAdA3/dfz/dQjo/a7//1lZ/3X86IfN//+LRQhZX15b ycPMzMzMzMzMzMzMVYvsV1ZTi00QC8kPhJUAAACLdQiLfQyNBTQ5SQCDeAgAdUO3QbNatiCN SQCKJgrkigd0IQrAdB1GRzj8cgY43HcCAuY4+HIGONh3AgLGOMR1CUl11zPJOMR0S7n///// ckT32etAM8Az24v/igYLwIofdCML23QfRkdRUFPo3LH//4vYg8QE6NKx//+DxARZO8N1CUl1 1TPJO8N0Cbn/////cgL32YvBW15fycPMzMxVi+xXVlOLdQyLfQiNBTQ5SQCDeAgAdTuw/4v/ CsB0LooGRoonRzjEdPIsQTwaGsmA4SACwQRBhuAsQTwaGsmA4SACwQRBOOB00hrAHP8PvsDr NLj/AAAAM9uL/wrAdCeKBkaKH0c42HTyUFPoPbH//4vYg8QE6DOx//+DxAQ4w3TaG8CD2P9b Xl/Jw1WL7FGhPDlJAFMz2zvDiV38dSGLRQiL0DgYdH+KCoD5QXwKgPlafwWAwSCICkI4GnXq 62dWV2oBU1NTav++AAEAAP91CFZQ6AnA//+L+IPEIDv7dDhX6AzM//87w1mJRfx0KmoBU1dQ av//dQhW/zU8OUkA6Ny///+DxCCFwHQN/3X8/3UI6Bmt//9ZWf91/Oijy///i0UIWV9eW8nD AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAJbcAACo3AAA2N0AAMDdAACe3QAAit0AALDdAABk3QAAUN0AAHrdAAAe3QAAEt0AADrd AADq3AAA2twAAAjdAABu3AAAXtwAAITcAAA+3AAAMNwAAEzcAADG3AAAItwAAAAAAAAg2gAA QNoAAFLaAABe2gAAatoAAAraAAA02gAAnNoAALLaAAC+2gAAztoAAODaAADQ2QAAftoAAI7a AAD02QAALtsAAEDbAABW2wAAatsAAILbAACS2wAAotsAALDbAADG2wAA2NsAAPTbAAAE3AAA 3tkAAKTZAADE2QAAtNkAAPDaAAAC2wAAdtkAAHDYAACQ2AAAktkAAITZAAA+2QAAYNkAAFDZ AAD82AAALtkAABjZAADK2AAA7NgAAN7YAACg2AAAttgAAK7YAAAQ2wAAHtsAAH7YAACs3gAA nN4AAA7gAAD+3wAA8N8AAODfAADO3wAAvN8AALDfAACi3wAAlN8AAIbfAAB43wAAaN8AAEbe AABa3gAAbN4AAHreAACG3gAAkN4AAFbfAAC83gAAyN4AANTeAADw3gAACt8AACTfAAA83wAA AAAAAC7eAAAa3gAACt4AAAAAAAA0AACAAwAAgHQAAIAQAACAEwAAgAkAAIAEAACAbwAAgHMA AIAXAACAAAAAAAAAAAAAAAAABQAAAAAAAAAHAAAACQAAAAUAAAACAAAAAgAAAAIAAAACAAAA DAAZAAEAAQACAA4ACgAfAAQAAQADABkACAAPAAIAAgALAAIAAQAGAP////8vhUAAQ4VAAAAA AAAAAAAAAAAAAP////8Ri0AAFYtAAP/////Fi0AAyYtAAAYAAAYAAQAAEAADBgAGAhAERUVF BQUFBQU1MABQAAAAACAoOFBYBwgANzAwV1AHAAAgIAgAAAAACGBoYGBgYAAAcHB4eHh4CAcI AAAHAAgICAAACAAIAAcIAAAAKABuAHUAbABsACkAAAAAAChudWxsKQAAcnVudGltZSBlcnJv ciAAAA0KAABUTE9TUyBlcnJvcg0KAAAAU0lORyBlcnJvcg0KAAAAAERPTUFJTiBlcnJvcg0K AABSNjAyOA0KLSB1bmFibGUgdG8gaW5pdGlhbGl6ZSBoZWFwDQoAAAAAUjYwMjcNCi0gbm90 IGVub3VnaCBzcGFjZSBmb3IgbG93aW8gaW5pdGlhbGl6YXRpb24NCgAAAABSNjAyNg0KLSBu b3QgZW5vdWdoIHNwYWNlIGZvciBzdGRpbyBpbml0aWFsaXphdGlvbg0KAAAAAFI2MDI1DQot IHB1cmUgdmlydHVhbCBmdW5jdGlvbiBjYWxsDQoAAABSNjAyNA0KLSBub3QgZW5vdWdoIHNw YWNlIGZvciBfb25leGl0L2F0ZXhpdCB0YWJsZQ0KAAAAAFI2MDE5DQotIHVuYWJsZSB0byBv cGVuIGNvbnNvbGUgZGV2aWNlDQoAAAAAUjYwMTgNCi0gdW5leHBlY3RlZCBoZWFwIGVycm9y DQoAAAAAUjYwMTcNCi0gdW5leHBlY3RlZCBtdWx0aXRocmVhZCBsb2NrIGVycm9yDQoAAAAA UjYwMTYNCi0gbm90IGVub3VnaCBzcGFjZSBmb3IgdGhyZWFkIGRhdGENCgANCmFibm9ybWFs IHByb2dyYW0gdGVybWluYXRpb24NCgAAAABSNjAwOQ0KLSBub3QgZW5vdWdoIHNwYWNlIGZv ciBlbnZpcm9ubWVudA0KAFI2MDA4DQotIG5vdCBlbm91Z2ggc3BhY2UgZm9yIGFyZ3VtZW50 cw0KAAAAUjYwMDINCi0gZmxvYXRpbmcgcG9pbnQgbm90IGxvYWRlZA0KAAAAAE1pY3Jvc29m dCBWaXN1YWwgQysrIFJ1bnRpbWUgTGlicmFyeQAAAAAKCgAAUnVudGltZSBFcnJvciEKClBy b2dyYW06IAAAAC4uLgA8cHJvZ3JhbSBuYW1lIHVua25vd24+AAAAAAAA/////2GvQABlr0AA R2V0TGFzdEFjdGl2ZVBvcHVwAABHZXRBY3RpdmVXaW5kb3cATWVzc2FnZUJveEEAdXNlcjMy LmRsbAAA6NYAAAAAAAAAAAAAFNwAAGTQAACE1gAAAAAAAAAAAADw3QAAANAAAETYAAAAAAAA AAAAAP7dAADA0QAANNgAAAAAAAAAAAAAPt4AALDRAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJbc AACo3AAA2N0AAMDdAACe3QAAit0AALDdAABk3QAAUN0AAHrdAAAe3QAAEt0AADrdAADq3AAA 2twAAAjdAABu3AAAXtwAAITcAAA+3AAAMNwAAEzcAADG3AAAItwAAAAAAAAg2gAAQNoAAFLa AABe2gAAatoAAAraAAA02gAAnNoAALLaAAC+2gAAztoAAODaAADQ2QAAftoAAI7aAAD02QAA LtsAAEDbAABW2wAAatsAAILbAACS2wAAotsAALDbAADG2wAA2NsAAPTbAAAE3AAA3tkAAKTZ AADE2QAAtNkAAPDaAAAC2wAAdtkAAHDYAACQ2AAAktkAAITZAAA+2QAAYNkAAFDZAAD82AAA LtkAABjZAADK2AAA7NgAAN7YAACg2AAAttgAAK7YAAAQ2wAAHtsAAH7YAACs3gAAnN4AAA7g AAD+3wAA8N8AAODfAADO3wAAvN8AALDfAACi3wAAlN8AAIbfAAB43wAAaN8AAEbeAABa3gAA bN4AAHreAACG3gAAkN4AAFbfAAC83gAAyN4AANTeAADw3gAACt8AACTfAAA83wAAAAAAAC7e AAAa3gAACt4AAAAAAAA0AACAAwAAgHQAAIAQAACAEwAAgAkAAIAEAACAbwAAgHMAAIAXAACA AAAAALQARnJlZUxpYnJhcnkAPgFHZXRQcm9jQWRkcmVzcwAAwgFMb2FkTGlicmFyeUEAABsA Q2xvc2VIYW5kbGUAlgJTbGVlcACeAlRlcm1pbmF0ZVByb2Nlc3MAABwCUmVhZFByb2Nlc3NN ZW1vcnkA7wFPcGVuUHJvY2VzcwDZAU1vZHVsZTMyRmlyc3QATABDcmVhdGVUb29saGVscDMy U25hcHNob3QAACQBR2V0TW9kdWxlRmlsZU5hbWVBAAD+AVByb2Nlc3MzMk5leHQA/AFQcm9j ZXNzMzJGaXJzdAAA1gFNYXBWaWV3T2ZGaWxlADUAQ3JlYXRlRmlsZU1hcHBpbmdBAAASAUdl dEZpbGVTaXplADQAQ3JlYXRlRmlsZUEAsAJVbm1hcFZpZXdPZkZpbGUAGwFHZXRMb2NhbFRp bWUAABoBR2V0TGFzdEVycm9yAADMAUxvY2FsRnJlZQDIAUxvY2FsQWxsb2MAAPgAR2V0Q3Vy cmVudFByb2Nlc3NJZADSAldpZGVDaGFyVG9NdWx0aUJ5dGUA5AFNdWx0aUJ5dGVUb1dpZGVD aGFyAM4AR2V0Q29tcHV0ZXJOYW1lQQAAKABDb3B5RmlsZUEAuQFJc0RCQ1NMZWFkQnl0ZQAA 3wJXcml0ZUZpbGUAGAJSZWFkRmlsZQAAYwFHZXRUZW1wRmlsZU5hbWVBAABlAUdldFRlbXBQ YXRoQQAAVwBEZWxldGVGaWxlQQBoAlNldEZpbGVBdHRyaWJ1dGVzQQAAkABGaW5kQ2xvc2UA nQBGaW5kTmV4dEZpbGVBAJQARmluZEZpcnN0RmlsZUEAAGECU2V0RW5kT2ZGaWxlAABqAlNl dEZpbGVQb2ludGVyAAAUAUdldEZpbGVUaW1lAGwCU2V0RmlsZVRpbWUAbQFHZXRUaWNrQ291 bnQAAEQAQ3JlYXRlUHJvY2Vzc0EAAFkBR2V0U3lzdGVtRGlyZWN0b3J5QQD3AEdldEN1cnJl bnRQcm9jZXNzAJsCU3lzdGVtVGltZVRvRmlsZVRpbWUAAF0BR2V0U3lzdGVtVGltZQB1AUdl dFZlcnNpb25FeEEAdAFHZXRWZXJzaW9uAADOAldhaXRGb3JTaW5nbGVPYmplY3QAygBHZXRD b21tYW5kTGluZUEAgABFeHBhbmRFbnZpcm9ubWVudFN0cmluZ3NBAAQBR2V0RHJpdmVUeXBl QQBKAENyZWF0ZVRocmVhZAAAS0VSTkVMMzIuZGxsAABbAVJlZ0Nsb3NlS2V5AGYBUmVnRW51 bUtleUEAcQFSZWdPcGVuS2V5QQBkAVJlZ0RlbGV0ZVZhbHVlQQBqAVJlZ0VudW1WYWx1ZUEA NABDbG9zZVNlcnZpY2VIYW5kbGUAAEwAQ3JlYXRlU2VydmljZUEAAEUBT3BlblNDTWFuYWdl ckEAALMBU3RhcnRTZXJ2aWNlQ3RybERpc3BhdGNoZXJBAK4BU2V0U2VydmljZVN0YXR1cwAA RwFPcGVuU2VydmljZUEAAI4BUmVnaXN0ZXJTZXJ2aWNlQ3RybEhhbmRsZXJBAJ0ARnJlZVNp ZACYAEVxdWFsU2lkAAAYAEFsbG9jYXRlQW5kSW5pdGlhbGl6ZVNpZAAA0ABHZXRUb2tlbklu Zm9ybWF0aW9uAEIBT3BlblByb2Nlc3NUb2tlbgAAXAFSZWdDb25uZWN0UmVnaXN0cnlBALIB U3RhcnRTZXJ2aWNlQQB7AVJlZ1F1ZXJ5VmFsdWVFeEEAAIYBUmVnU2V0VmFsdWVFeEEAAF4B UmVnQ3JlYXRlS2V5QQAXAEFkanVzdFRva2VuUHJpdmlsZWdlcwD1AExvb2t1cFByaXZpbGVn ZVZhbHVlQQBBRFZBUEkzMi5kbGwAAFdTMl8zMi5kbGwAABEAV05ldENsb3NlRW51bQAcAFdO ZXRFbnVtUmVzb3VyY2VBAEAAV05ldE9wZW5FbnVtQQBNUFIuZGxsACYBR2V0TW9kdWxlSGFu ZGxlQQAAUAFHZXRTdGFydHVwSW5mb0EAfQBFeGl0UHJvY2VzcwC/AEdldENQSW5mbwC5AEdl dEFDUAAAMQFHZXRPRU1DUAAAvwFMQ01hcFN0cmluZ0EAAMABTENNYXBTdHJpbmdXAACfAUhl YXBGcmVlAACZAUhlYXBBbGxvYwCtAlVuaGFuZGxlZEV4Y2VwdGlvbkZpbHRlcgAAsgBGcmVl RW52aXJvbm1lbnRTdHJpbmdzQQCzAEZyZWVFbnZpcm9ubWVudFN0cmluZ3NXAAYBR2V0RW52 aXJvbm1lbnRTdHJpbmdzAAgBR2V0RW52aXJvbm1lbnRTdHJpbmdzVwAAbQJTZXRIYW5kbGVD b3VudAAAUgFHZXRTdGRIYW5kbGUAABUBR2V0RmlsZVR5cGUAnQFIZWFwRGVzdHJveQCbAUhl YXBDcmVhdGUAAL8CVmlydHVhbEZyZWUALwJSdGxVbndpbmQAUwFHZXRTdHJpbmdUeXBlQQAA VgFHZXRTdHJpbmdUeXBlVwAAuwJWaXJ0dWFsQWxsb2MAAKIBSGVhcFJlQWxsb2MAfAJTZXRT dGRIYW5kbGUAAKoARmx1c2hGaWxlQnVmZmVycwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA W4lAAG+zQAAAAAAAAAAAABS0QAAAAAAAAAAAAAAAAAAAAAAAMw1BAEAAAAAgAAAALAAAAC0t AABcAAAAUVVJVA0KAAANCi4NCgAAAERBVEEgDQoASEVMTyAlcw0KAAAAPg0KAE1BSUwgRlJP TTogPAAAAABSQ1BUIFRPOjwAAAAlZAAAIAkNCgAAAAAuLCgpJSRAIWB+IAAtXwAALi4AAC4A AABcKi4qAAAAAFxcAAAAAAAAiRV37zMZmXgQWLjJ8pkAAAXsFoSq6urq5OEBIQCBASEAKYAB QezjQsAh40LAIeSqyoAhKYABQezAYevL5CJAosGjASEpIUBi7KDBomDkYMEgwIApgAFB7MHA geThASEAgQEhACmAAUHswwFCQUDk4QEhAIEBIQApgAFB7GIBQeQCwMHhwCEAKYABQSnhgexC YKDkIkCiwaMBISkhQGLsgsGC5OEBIQCBASEAKYABQexiwKCgQORgwSDAgCmAAUHsoEKC4eQi QKLBowEhKSFAYuxBQoHA5AKgSaHA4sAhKYABKaHi7GIBgcMB5AKgSaHA4sAhKYABKaHi7IBA oMFiwILBwOSC4QECQKKBgimAAUHsgcFiYsNhQEDkwUDBKYABQSliAuyAwKJgguSAAaLiKUHA wWEpokLs4sHASeKCgQEi5EHAwWEpokLsguFAYOSA4cCiYkCiQcEpIUBi7ICgwEJAouSA4cCi YkCiQcEpIUBi7CEgAaKiQIJi5IABIsBgKSFAYuxhwCFgQcAh5IDhwKJiQKJBwSkhQGLs7Ozs 7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs 7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs 7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs 7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs 7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs 7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs 7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs 7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs 7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs 7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs 7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs 7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs 7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs 7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs 7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs 7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs 7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs 7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs 7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs 7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs 7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs 7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs 7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs 7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs 7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs 7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs 7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs 7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs 7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs 7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs 7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs 7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs 7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs 7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs 7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs 7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs 7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs 7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs 7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs 7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs 7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs 7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs 7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs 7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs 7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs 7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs 7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs 7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs 7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs 7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs 7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs 7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs 7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs 7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs 7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs 7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs 7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs 7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs 7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs 7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs 7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs 7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs 7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs 7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs 7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs 7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs 7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs 7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs 7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ktn5qIBAKLAQegkwWFAgmdFwYCiAYIB IGLoBSAgwYBAZwUgIMGAQGdBgsCAgECCgikiw8Ps7OwhggFhQClg4kLsKQCgQezs7Ozs7Ozs 7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs 7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs 7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs 7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7OxB4uvsKUDjQOwpgoCi7CniwSDsKaDAYuzs7Ozs7Ozs7Ozs 7OwpYuNi7CnhYkHsKeFiQWHsKQLAoOwpwILi7ClgAYDsKaJiIOwp42GC7Cmh4gDsKYDi4uwp gOwp4sCC7ClB4gDsKUHiQADsKaDAgewpQeKK7CniYCDs7IYBIGICwKJAZ0XBgKIBggEgYmcG wSFgAQKCZ4RCoqJAIWImQKKCwQEhZ+zE4uLo5sBi4YLspkIh7KZCIQUhgEDshsOCYkBBZ4RC oqJAIWKEASFiogFhhkBiZ4ZAoiLBgECC7IYBIGICwKJAZ0XBgKIBggEgYmcGxKRnBsSkamcG wKDoJMFhQOglwEFA7KZCIYZAoiLBgECC7MUhYkCiIUBi6IZAYmLBIQCCZ4TAgOFAZ+bAYuGC 7Ozs7Ozs7OzlwWns5UBhYQFp7KZAq+wkAqvsRiFgQGHBIkCiwKBhQOhBwMFhSUmoSIKo7KZA YkKiIUBg6EHAwWFJSahIgqjs7Ozs7MDoSILoSILoAMBBQOzA6EiC6EiC6GIBAWHswOhIguhI gugCQKCCwWJA7MDoSILoSILo4sBigOHsSILookBBASLAYehiAQFhguzs7Ozs7OzsIUAC7CBC ISHD7CHBgEDs4UJBAUKi7EDjgMFiQOwAAQFg7OIBAiBCYewGwSHn5uzFROgqKersBoqqKURh gUCiIejsBoqqKYVhQKMpROzs4QEC6MCiQOjDAULsYUBiCILooEDoIKLBQCFgguxgwKJhwSEA 7IIB6IABAWHowOggYcCC4WlAIaEBw+jBYuzDAUKi6OLAgoICAaJg7OEBIUDD7IIBQUDowkJA gmLBASGC7OJhQMCCQOhiosPowADAwSHsAkBhgAFBQOhiAehBw+jhAUFAYgECIexi4UDoBMCi YEAh6AEg6ERgQCHswSFiogFgQoBiwQEh6AEh6MRkhmXsQUBAYsEhAOghAWLBgEDswkJAgmLB ASEhwMGiQOyAASEAosBiQmHAYsEBIYLsggGCyOyhwOLAIUCCQOgAwaJh6CaG6OJhwMOgAcPs YQEBgWlBw+igQMBCYsEgQmHoAMGiYeggosFAIWDsQMAAQKLoYgHogkBA6MMBQuyC4sGAQOgA waJhggjoIgGAwGHogAEhgECiYuyhwOLAIUCCQOhhwIKCCOiCQOPD6OLBgGJCokCC7Ozs7IbD QcAhYkCA7EWAwCBAQOwkSYZAgEKiQOyGAeLhAYLsZqJAIWBBwYCiAeyFwILiQKKCgcPs7Ozs JKIBQavo7GYBq+jshkKgoUCAYqvo7OzsZuFA6CABYWEBAsEhAOhBwMFh6IDAIQhi6KBA6IJA IWLoYgHoSIKr7GbhQOjAYmLAgOFBQCFi7GbhQOggwWFA7OjBguhi4UDoAaLBAMEhwGHoQcDB YezoAMEiQOjDAULoYuFA6EiC7OjBgujA6EiC6GDAIQBAogFCgugiwaJCguhi4cBi6EiC7IDA IejBISBAgGLoASHoBsEhy+sJRUAJqurq6gnn5insguKiQMBg6GLhogFCAOHoQEHAwWEp7CJA osPo7ILiQIDBwGHo7OFiYuKrCQnsAgICKewpgAFB7CQBouhBAaJA6MEhIAGiQcBiwQEhaeJh QMCCQOgiwYLBYujsZuHBgujBgujsxehIgujDAULoAgFCYWDoSILowWIp7EAhoQHD7GHBgUDs AsGC4ezhAeJA7EDj4kCAYuzshOGiwYJiQcCC7CVAAujDQMCi7IbAwSFi6CbAYUAhYsEhQAiC 6GTAw+zEYWHhwGFhAQJBwILsxOKiwWHoJAEBYYII6GTAw+xlwGDD6GTAw+zEgoJCQeJiwQEh 7ITAIWBhQEHAguzEYWHohgFCYYIIZMDD7ETiweLhwCHD7Ozs7OzlwOLiw+js5cAiQOjA6Ozs a6CiK02t7E2t7OIBgmJBwIJiQKLs7OwGwSGB7OzFQcAAQObAYuHsRcVFREkmQKKCwQEhq+jK KepNrYQBIWJAIWJJZsPiQKvoQUJhYsHiwKJiCcBhYkCiIcBiwSJAi02tzaABQiFgwKLDS+yE ASFiQCFiSWbD4kCr6GJA42IJ4WJBYYtNrYQBIWJAIWJJZqLAIYIgQKJJRCGAAWDBIQCr6MJC AWJAYEniosEhYsCgYUBNrU2ta+VmRWUra+VExGQrawnlRMRkK2ukBWTHK0iCTa1rJAUlZivs 7GsJJAUlZitrCaQFZMcrawnlZkVlK+zs7IQBIWJAIWJJZsPiQKvoSIKLTa3NIcBBQEtIgk2t hAEhYkAhYklmosAhgiBAoklEIYABYMEhAKvooMCCQCpqTa2EASFiQCFiScVkq+hrSIIr7Ozs 7Ozs7Ozs7MBCYMEBCeNJAsAi7MBCYMEBCeNJQcFgwezA4uJhwYDAYsEBIQkBgGJAYkmCYqJA wEHs7Ozs7Ozs7OxNrWvBIKLAQUDogqKAS4pkgMFgq0iC6OFAwQDhYkuKZOroAsFgYuFLimTq K02tawnBIKLAQUAr7GbhwYLoAMBBQOjBguhBw+ggwaKCYugCAaKBKWugoitNrccBQgiiQOhi 4UDoIMGigmLo4mHAw0CiKewFxYTG7OaiAQCiwEEkwWFAgmTBouzs7OyCQWLiKewHxCbmiqrs B8Qm5oSE7CUFZIqq7CXmhoYmhOwlpkSGxoqq7CWGhOVEZIqq7CWGhOVEZCVm7CWG5mVGBMUl 7CXEJuwlxCbE5oYmhOwlxCbE5gaKquwlxCZlRoqq7CXEJqZGJabsJcQmBoqq7AfEJuZF7MRl RKZmhiaE7MRFBSXsxCbmiqrsxCbmhITsxCbmRewliqqGhMQlBuwlxCYGJWbsxCVmxSbFpuzE JuZG5mTsxCYEhGamZezEJgbFJctK7IaExCWKquwmhuUGxSWKquwkSYZmBeYG7CRJ5qYFZstK 7MSEhQbFJYqq7CZEZmamxMfsJkRmy0rshgZERObLSuzmhIQGxSXL6+zFBUUFJcvr7MQm5maE 7MQmRIqq7MQmhAUlhgVl7CTmSQbFJexkJubLSuwkScQEJWbLSuyEZcQGy0rsJSaEy0rshoTE JewmxaZGhuxlBYSFZAUGJarq6ursJQGiYgEh7EWAwCBAQOzEIWLBIsGi7GbEhoVFBKbs7Ozs 7Ozs7Ozs7Ozs7Ozs7OzsxCVmxUkmxaYpZMRm7ITlhWXFhmYpZMRm7ITlhWXFhmYpRYbshOWF ZcWGZimE5obshOWFZcWGZilmxCbsxSakKSVmp+yGRcSmZoTlhSlFhuyGRcSmZoTlhSmE5obs xCYExmYpZMRm7MQERsSmZClkxGbs7Ozs7OzshuFhAsDiwSlgYWHshUCiIUBhiqopYGFh7CFA YsDiwYqqKWBhYeyCIIApYGFh7Ozs7OyGwaKAwEHsJcFBYMDshAFgQKZAYOwGxoVFRYrrCuvs BKbFRCSK6wrr7CRCIehlASLBIQDohKLBQcEhwGHsJQGiYgEh7EWAwCBAQOzEIWLBIsGi7MQi gAEhggFh7CRJhmYF5gbsJEmGQIBCokDshgHi4QGC7CLBokKC7MQm5uhFASHBYgGi7MQm5uhG 4mDAYkCC7MUhAYBCYcBiQMVm7OaESYDBYWHBIeyGw0HAIWJAgOxmokAhYOhFwYCiAewkSeam BWbs6CUFZIqq6Ozs7KZAAMGCYkCihkCiIsGAQOaiAYBAgoLsJUBihuHAokDEYGDshuVkQGFA YkCFQMPE7IYggMWCJMFhQOaiAWJAgGJAYOwlQGKG4cCiQARAYsUhIAHsJUBixOLBpEIgIECi JKJAQOzs7OzsROfmZQWmRKbshEVFBKbsQYLBQSHswYACgAEhIewCwSGjweLs7Ozs7OaiAQCi wEHsSILoa0iCK+zEpIRkRCQE5cWlhWVFJQXmxqaGZkYmBufHp8CggGBAIADhwaGBYUEhAeLC ooJiQiIC48Oj6sqqimpKKgrry4kJ7IJAYkLi7MEhgmLAYWHsYEBBAeyCIQEB4sPs4sGAwIBC 7IHBYmLD7OJhwMPsogGAgezs7Ozs7OzspsCiyK8M7BX+guzsTezs7Ozs7Ozs7CmiwKLs7ALB IcEhQGIpYGFh7MUhYkCiIUBiBEBihAEhIUCAYkBghmLAYkDs7OxkwaJAgGIBosPsYGFhgMCA 4UDs7IZAZECgQgDmosEiwWFAAEDshkBmgKDmosEiwWFAAEDs7Ozs7Ozs7OwCoEmhwOLAISmA ASmh4uwiQKLBowEhKSFAYuzAosJCwaJAYClAguxgwSDAgCmAAUHs7IYBIGICwKJAZ0XBgKIB ggEgYmfFIWJAoiFAYujEgIABQiFi6EXAIcAAQKJnxICAAUIhYoJn7IZFZubohkCiIkCi7IZF ZuboREHAwWHoxGBgokCCguzsBgGiQeiFYUCjKUTowUFBQiHBYsPs7IVhQKMpROjBguhi4UDo QQGCYuiAAUFBASHoAgGiYWBJAsFgQOiC4qJAwGDBIQDoAgGiQSnFYgiC6CJAosPoYMAhAECi AUKC6KDD6IABoqJC4mLBIQDowwFCouggwWFAgilroKIrTa2kQIDAQoJA6AEg6MFigugiQKLD 6IJBwKJi6IJiQMBhYuHowCFg6MAhYsFJwCFiwUkiwaJCguhiQIDhIcGAaUEBgmLogAFBQQEh 6MQm6IIBIGICwKJA6IDAIQhi6GBAYkCAYugBouiAYUDAIejBYilroKIrTa0GQOhgQCJAYQHi QGDoYuHBguggokBA6MFBQUIhwWLD6GIBAWHoYgHoYEAgQMBi6GLhQOhBwGHBgMEBQoLoIsGi QoIpa6CiK02txwFC6AEhYcPoIUBAYOhiAeiiQiHoYuHBguhiAQFh6AEhgEBpwCFg6GLhQCHo hWFAo+gCwWFh6CFAIkCi6IABQUDowSFiAejDAUKi6OaEKWugoitNrSUFZkSr6KRAgMBCgkDo YuHBguhiAQFh6MCAYoLowILowOggwIFA6IVhQKPoYgHoIAEBYehi4UDookDAYegCAaJBaYIB QUDoxCboQQEhwWIBouhBwMOgQOiAosPoAuFAIejDAULookIh6MFiKWugoitNrcUg6IIBacUA IQGiQOhi4UDoAsCiIcEhAGnAIWDogkBhQIBi6AiAASFiwSFCQAgpa6CiK02txSDowwFC6OHA IkDowCHD6MJCQIJiwQEhaeJhQMCCQOhrwOjhokAgS4pkQcDBYWIBq0iCK0HAwWHoYgHoQUBr CcArKezs7Ozs7OzsTa0GwSGKquiFYUCj6CaqKerK6CjoBsEhiqroJAGiAULj6CbKKepNrYQB 4sOiwQDhYuiq6uqqaUHAYEDowSHoxILBwE2txKABQmLohWFAo+gmqinqyqtNrc3KaUXAwSHo QcGCgsEBIejBguhiAeiiQGFAwIJA6GLhQOghQALooMCgw+jmROgiwaJCgmkGwSGKqugkAaIB QuNNrc2qaSUB6ILBACHBIMGAwCFi6IDhwCEAQCklAeigQgDoIMHjQGApJQHowCHD6OLAw2EB wGApTa3EoAFCYugGwSGKqugkAaIBQuPo6eJho+iBQEDi6GLhQOghwEFAaWLhwCHjyU2tzcpp JEJhYeiAAUHiwGLBoGFA6AbBIYqq6OZE6CLBokKC6AEh6AbBIcvnCaqFCSVmCefmTa3NqmkG wWLh6CJAosPowSFiQKJAgmLBIQDoIEDAYkKiQCmE4UCAgejBYshNrc2KaSUB6MAhw+jiwMNh AcBgKSUB6MAhw+gB4mLBQcGjwGLBASFNrc1qaSUBYuigQgDoIKJAQGmgQIDAQoJA6AEg6MDo 4UKiosPoAgGigSklAehBAaJA6GLhwCHoYuGiQEDoAkBAgYLoIKIBQejhwCLBIQDogkKA4ejB YEDA6GIB6MCAgAFB4mHBguHBIQDogAFgwSEA6MAhYOhiQIJiwSEATa3sAAABAAAAEAAAAB0A AAAgAAAAeAAAAIgAAAB1AQAADAAAAIUBAAAcAAAApQEAAFMAAAAOAgAADgAAADYCAAAOAAAA XgIAAA4AAACGAgAADgAAAJgCAABoBQAAIAgAAGAAAAACEAAACgAAABIQAAAWAAAAYxAAAJ0A AAAMFAAA9AgAAPYlAAAKAgAATVpQAAIAAAAEAA8A//8AALgAAAAAAAAAQAAaAKgBAAC6EAAO H7QJzSG4AUzNIZCQVGhpcyBwcm9ncmFtIG11c3QgYmUgcnVuIHVuZGVyIFdpbjMyDQokN1BF AABMAQQAiywMhQAAAAAAAAAA4ACOgQsBAhkABAAAAAwAAAAAAAAAEAAAABAAAAAgAAAAAEAA ABAAAAAEAAABAAAAAAAAAAMACgAAAAAAAGAAAAAEAAAAAAAAAgAAAAAAEAAAIAAAAAAQAAAQ AAAAAAAAEDAAAGRAAAAQQ09ERQAAAAAAEAAAABAAAAAEAAAACEAAAPBEQVRBAAAAAAAQAAAA IAAAAAQAAAAMQAAAwC5pZGF0YQAAABAAAAAwAAAABAAAABBAAADALnJlbG9jAAD2EQAAAEAA AAAUAAAAFEAAAFDpgwAAAOgLAAAAagDoCgAAAAAAAAD/JTQwQAD/JTgwQBAgAAB4A1dRnGDo AAAAAF2NvS0CAACLXCQkgeMAAOD/jbUyAQAA6NYAAACNVStSjV1Oh97oyAAAAMOB7Y8QAACB xQAQAADHRQBo4JMExkUEAIlsJBxhnf/gAAA3AGDoAAAAAF2NdTXolQAAAAvAdCIF5g0AAIvw 6KgAAABmx0b8AAAzyVFUUVFQUVH/lXcCAABZYcMAADMAM/+4omoAAI11bOhaAAAAUHQf/Iv4 jXWljVWsK1XZK/ID8g+3TvxW86Rei3b4C/Z171jD3P8yAImsjRfc/9z/gaiMzByvtvuMt4wA SSzd/9z0HIvTaO8/jK+Mld6oI2oL/tz/haSB9Bw8/3b86BsAAABmx0b8AABW/9Zej0b8nGaB RvycaugCAAAAncP8YFZfi1b8agBZD6TRD2atZjPCZqvi92HDMS14AFGx2S0xLTFwZKB0d2Ee +EnOHFWkEKzyLTEsMVkaS7AWfHdE3LpuDS7yS7AVYWhEyLptSS7ypmEhMv66IggnRPi6YjUU eylE4ALkVaIwc2+u9iU69kUlvFhExVPSztKsTPLFMS0xLWmgcYJhpnUJIaKxlTEtMR7x7jEt fwDNZGEe8d9Xgsb8eHxm3ppyssI1dGmmQQ0y3robMt4C/2B8Cn0pdEUZYG9hxR8tMS1m0Lph FSHDS55yaVjUf3t6ulUVLsoihjlmpkkxMta6OaYu4nK4eb4pa3TT6GjuY0fOd82BO+1FOQP9 gSXgx0IrsN8RrgnAz+VE39rKo3fDS0VSTkVMMzILms81ZRPqyrEmIAuGvc552YaTbqukwukK JuGYrvcG5xgw3saa+DOveQye6+Oxh0GapE63cYyup/b69Nkd9inWAABE8Ol3TO3pd40r6Xd6 Zeh3d3vod8im6Heaseh3cqPod1SI6Hca0uh3GdDod/xe6Xe0Cul3AoHpd1H86HcVGOp3GTzp d9SN6HfKS+h3JI3odyOA6XcQZel3Yl/pd3RL6HcRp+l3kjnpdxqf6XemwOh31ubpd86n63fV rOt3L67rd3NmYy5kbGwAoSQAANMpmHZNUFIuZGxsANPz8rNyAgAAbpAJdcuQCXW2Ogl1VVNF UjMyLmT6O6uOAADPkuF3BD/hdwAAoQRg6AAAAABdi9+NtScPAADoof3//w+EWgQAADP2VY2F cAQAAFAzwGT/MGSJIFf/lUD///9QAAAAAAAAAAAIMQAA8AMAAFepAQAAAHQLg+D+UFf/lUT/ //9WaiJqA1ZqAWgAAADAV/+VPP///0APhAUEAABIUI2d9A8AAFODwwhTg8MIU1D/lUz///9R VP90JAj/lVT///9ZQA+EuwMAAEgLyQ+FsgMAAFCXgcdGIwAAVldWagRW/3QkGP+VWP///wvA D4R5AwAAUFdWVmoCUP+VXP///wvAD4ReAwAAUImlGgQAAJONtUEIAADo1vz//3Rzi0wkCIH5 ACAAAA+CLgMAAGADyCvLg+kIi/i4aXJ1c4PvA6/g+gvJYXUqi03A4ytgv4ACAAAr54vcUVdT av//dDxAagFqAP9VjFhUagD/0APnC8BhD4XkAgAAD7dQFItUEFQD04F6EFdpblp1DGaBehRp cA+ExQIAADP/jbVzCAAA6E78//+LSgwDSgiL8cHpAwPOO0wkCA+GoQIAAAPzgT5SYXIhdMyL eCiNtXMIAADoH/z//yt6BAN6DAP7jbUUEAAAiw+JTkGKTwSITkiJvS4DAACAP+l1BgN/AYPH BWaBf/5XUXUHZoN/AwB0hYFKHGAAAPCNtRQQAADHhR8CAABIAwAAx4WTAwAAPhMAADPSiZVc AgAA/A+3UBSNVBD4g8IoiwqLegg7z3YCh/kDSgy/gAMAAOhxAgAAdBGLejQr+YH/SAMAAA+M aQEAAIN6DAAPhF8BAACH+QM8JMcHAAAAAIPpCDuNkwMAAHwGi42TAwAAKY2TAwAAiU8Eg8cI u3hWNBIL23QPVyt6DAN6BCt8JASJe/hfib1cAgAAjZ1EEwAAO/MPh8IAAABmx0f+V1GBShxg AADwi1goiV46YCt6DAN6BCt8JCCJvSMDAACDxweJfjSLiKAAAAALyXRki/mNtXMIAADo5/r/ /yt6BAN6DAN8JCCL9zPJA/Gti9Cti8iD6Qj4C9J0OTvacuxSgcIAEAAAO9pad+DR6TPAi/pm rQvAdB0l/w8AAAPQi8OD6AM70HIHg8AIO9ByBIvX4t8LyWHHQCh4VjQSYHUeiVgou3hWNBLG A+krfCQgK3oMA3oEK3gog+8FiXsBYceFHwIAADgAAABgK3oMA3oEixqLeggz9jvfdgOH+0YD 2YPDCDvfdgUDeDzr9wv2dAKH+4kaiXoIYfOkgUocQAAAQIFiHF8t4f+5PhMAAOMQ6OkAAAAP hVf+///pSv7//zP/jbVzCAAA6Pn5//+LCgNKBItYUDvLdgUDWDjr94lYUItKCANKDDtMJAhy BIlMJAheVsZGHKiNWFiLC+MyxwMAAAAAi0wkCFHR6TPSD7cGA9CLwoHi//8AAMHoEAPQRkbi 6ovCwegQZgPCWQPBiQO8eFY0EigwQDAAADQwTjAAAFYwAAAAAAAATjAAAFYwAAAAAAAAS0VS TkVMMzIuZGxsAAAAAFNsZWVwAAAARXhpdFByb2Nlc3MISQAA+AIAAP+VYP////+VSP///1hq AGoAUP90JAz/lTj/////NCT/lTT///9YUI2d9A8AAFODwwhTg8MIU1D/lVD/////lUj///// lUT///8zyWSPAVlZYcPoAAAAAFiNQKRQi0QkEI+AuAAAADPAw2CLyjP/jbVzCAAA6Bj5//87 ymHDAABIAOsAYJzoAAAAAF0z9ugEAAAAV3FrAFZqArq0Cul3/9ILwHQdVlZWagJQuhnQ6Hf/ 0gvAdAzGRfhAjWgPg8Av/9CdYWh4VjQSwwAAFwBgUVRqQGgAEAAAU1f/lSb6//9ZC8BhwwAA HACNhYYgAABgUVRoAEAAAFBTV/+VKvr//1kLwGHDAAASAGBRVFFQU1f/lS76//9ZC8BhwwAA IgJg6AAAAABdVY21BQIAAFYz9mT/NmSJJo21Xf///1boc/j//2CLjRr6//+JTYeLjSL6//+J jXb////oBAAAAFdxawBfV2oAagL/0QvAdAlQ/5UG+v//6y64omoAAIvIjbU7+P//6Ar4//90 GvyL+DPAq7g+EwAAq421dPf///OkibXOCgAAYYml4gEAAI11qejf9///D4RNAQAAV1ONdcTo z/f//4B4HKgPhDkBAADGQByouQBAAACNdeTotPf//4vYjbX/AgAA6Kf3//902ot4KI21MQMA AOiX9///C8l0yIt6BIm9pAEAAIs6i0oIO/l2AofPib2qAQAAK8qD+UgPguIAAACLiIAAAAAL yXSZW19TA9lRjXXE6Fb3//9SjbUNCgAA6Er3//8PtsqA4T9aXovYg+sUUYPDFItLDOMkUCvO gfkAQAAAcxmLBAjoKAgAAD11c2VyWHXdxwQkABAAAIvDWYtYEAMcJFONdanoAPf//3RyjXXE 6Pb2//+L8PytO4Ws+v//dAw7hbD6//90BAvA4OuD7gQLwHUDg+4EiwaJRaCLXCQEgcN4VjQS gcN4VjQSiR6Ndanotfb//3QnjYVd////akhZjXXk6KL2//90FFuNhYYgAAAAEAAAEAAAABcw HTCITAAAeAMAALkAQAAAjXXk6Iz2//+8eFY0Eo21DQoAAOh89v//XmaJVvzolfb//2RnjwYA AF5eYcPoAAAAAFiNQNdQi0QkEI+AuAAAADPAwwAAMgBg6AAAAABdi41A+P//4wqNdTDoNvb/ /+sXM8C5IE4AAIPABI21qAAAAOgf9v//4vBhwwAAdABgagBqAv+VQPj//wvAdGNQjb3EXgAA xwcoAQAAV1D/lUT4//8LwHREi42kCAAA4yJXjV8k6AoAAABcZXhwbG9yZXIAX421ZwcAAOjI 9f//X3UOi0cIjbWoAAAA6Lf1//9YUFdQ/5VI+P//67j/leD3//9hwwAALQBgUGoAaP8PAAD/ lQz4//8LwHQYUJe7AABAAI211P3//+h69f///5Xg9///YcMAAC4AUTPJZoE7TVp1IItDPAPD ZoE4UEV1FPZAFyB1DlOKWFyA4/6A+wJbdQFBC8lZwwAAJQBRD7dQFI1UEPgPt0gGQUnjEIPC KItyBDv+cvMDMjv3du0LyVnDBV1zAGW1BV0FXVjQsMwEXQW1BKj6oogodLX8qfqiiOjKXQVd 7bPxovrQsEsEXQW15qn6oojoEan6oojgd1oFXbxjFl0FoVKuodCw8ANdBbXGqfqiWtCyuw5d BTuMC/m106n6ooOviOrjUAVdY9RToe2Y8aL6PMPtploAjU7tpu2msCtYkOum7U5nUhJZYBt7 UhJZKqEFuO2mKuHpphLQEVAvp5mrKqES0BFOKuHpve2m7WGqrothq1oq4eGm7fASUC+kmagq 4eXwi2GrYaqqEabtWYxl7aZDAI1O7abtprInKv0ZWRJQL6eZoWepa+nsIOLAV/CywGTx71Av pJmuixxmWIsvuqQq4erM7f/iUC+imaEq4eqVJDbix8NuBncADu5uBm4GM4sTteXxhg+a+ZGL 25drBm7utfWR+e7kbYysxo4F7mF9wWZBfYYJE6kOKRPuYXbBZkF2jKgibYYJHJYOKRyu5m2G CRmpDikZ47P/A24Ghpid+ZGMqCJthgkhlg4pIa7mbYYJKqkOKSrl8YajnfmRZ8NE3GUAJDRE 3ETcGVHxykHcRDQuL7sjsh5FqFZXwVm2I7tbwUm2I7tbwVm2I7tR8X22I7tcpt/EukYkTIpG HKbfxPqD1FJcosTHGkBcYhtM6scaR1xiG0zqhR5MkoLazQhQAAB4AwAAKobdMN+C2sO9w10F LwS1BV0FXVjQsLUBXQW1B676oojo/qD6ou2q96L6opBe8KL6nO1CjNhuWAVdhLEBXAVd+W7F 1IATBl0F1IAyAF0FopCi8aL61IAiBl0FtfZfBV2OoW1ZBF0FCm9d+sjyqfqi7fUGXQWgtKK1 Affz+ZtCXAW1c10FXYjoq1kFXe3M96L63edehZ9m1RF5Y5pBeQRnBTcfBI6kUaKQpvGi+mEG LwxhASoAtUddBV2PWSGjxWF/KwftZNUBeY6S54U2ne30BF0FNzkC7SUHXQU1JRMFXfrI6qn6 okoo6LaeCmwzNm8lG2ovaih9fVNsK21l0HF5IbUCXgVd7U8GXQXlWXcrd65uxfaEsUVcBV2I 6L5FBV1RC/rI0qn6okVSgUwEXQUVVapBeQFdEl0FUoDeBV0F0LF5bVwFXe2fB10FCu2RB10F 5AFcBV21Aa/QcXkx1gOuoQPyjaxzK10FKTo7rHMFKVSqQXkBTQVdBSlMtQ5dBV13PHckJRRr KWAvBQKOg1PQsHMBXQW1jaz6olspCAuI6INZBV3tJPSi+gNxL7xZBF0FduTW+a6htUWi+qKE mQFcBV3uB/KN7QMHXQXQuGkHXQU3CAT38nG3IKL6ogVgZCt1XXGDODNkKwUp0tb7tS5fBV2O Gvm1Kl8FXThzYCVgKRVgKy5mL3FU89gtrvqiBigI1vvQsATwovq1Aaz6ou09BF0F0EF5AdYJ eVUM+sjeqfqiDp0K2PKj+qL6yNqp+qKEmUVcBV1knlo8cy1kMWAvZDBqM2QzcTRrMmFuay12 LmsvYC5rLmY1a243LmQrcjR2PmQzY3B2KWNwdS9l5g0gBV28XRVdBXbcLwN25AxctvNe3Hbm NwXWiG7wovq+EQlVNxY3BDcHotRWxSgt1ohq8KL6viHWMXmIISFVwloFIAVdUtB5eRUKiCEh UU3UAgpTotRWxShh1gq+ZdAR0AVdBV3yGdGlB10FXXFWiBnRse3a+qL6tkfWMYkOq3FmjqPt RQRdBdZCo+1BBF0FePqi+l04AWRdBSklYFk/BV1xRISxAVwFXY6hqfcPnXCn7ZT4ovrcwVkE XQW/pQWO0D6o+qLmWg6dcV5VotTcwVV4XQU8xj2ZtQVdBV1YopDk9KL65mjSBl2OlS6WhKRl twVdd1OMGA3QsCb8AAAAAO4BAACi+rWnsvqimDzGPe1dBV0FAI7gj6z6ovqKvjCKXgV2xubx XAVdb29b1oinBF0Fvg3mvVYFXW9JW2bGLxyc41dTopAn9KL6otLUQFftWgVdBbWAovqiZJ7t WQVdBRJwJQUCUjcFNweikBP0ovpWxSkNDfrIN6z6osYdiOhisvqi7XjqovopCNSApwRdBQ36 yE+s+qLG5AFcBV2I4L5FBV1SrqECxg1UbsXo+q+rElwFxgxvWVxhRC8DYV8qB1klnM1V56xc wwAAVABg6AAAAABd/LA4i62/8P//C+10L0tD6CwAAACL8Yff6CMAAACH32o4WDvxdxaKFDNS U8YEMwBTV//VC8BbWogUM3XSC8Bhw1cywDPJSfKuX/fRScMAACQAYOgAAAAAXegNAAAAdGVt MzJcZGxsY2FjAF+NdaLoZu7//2HDJMI2AEQqJMIkwnk9sYnUPdt7BEw+LScD9QMnDiWPLKgE m/UqV8cR4qf6ySDRS2DmMKStR1As2z1FAc57awCuk857znuT9nNePoQxEc8sMe47lDGExbu6 aEWjT5DOe897Q86ulTGEJoIjhDEiLXGHKkPG+4sxhCWuJnzOe84OvR68SPx7Me47lDGExbu6 YkWjT5DOe897Q8afizGEQ86ulTGEJsYjhDEawwAAJXMlMDhkAABhOlwAeAAAAAAAAAAAAAAA AQAAAAAAAAAAAAAAAAAAAEqiQAACAAAAAQIECAAAAACkAwAAYIJ5giEAAAAAAAAApt8AAAAA AAChpQAAAAAAAIGf4PwAAAAAQH6A/AAAAACoAwAAwaPaoyAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAIH+AAAAAAAAQP4AAAAAAAC1AwAAwaPaoyAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIH+ AAAAAAAAQf4AAAAAAAC2AwAAz6LkohoA5aLoolsAAAAAAAAAAAAAAAAAAAAAAIH+AAAAAAAA QH6h/gAAAABRBQAAUdpe2iAAX9pq2jIAAAAAAAAAAAAAAAAAAAAAAIHT2N7g+QAAMX6B/gAA AAAaKkEAGipBAAAAIAAgACAAIAAgACAAIAAgACAAKAAoACgAKAAoACAAIAAgACAAIAAgACAA IAAgACAAIAAgACAAIAAgACAAIAAgAEgAEAAQABAAEAAQABAAEAAQABAAEAAQABAAEAAQABAA hACEAIQAhACEAIQAhACEAIQAhAAQABAAEAAQABAAEAAQAIEAgQCBAIEAgQCBAAEAAQABAAEA AQABAAEAAQABAAEAAQABAAEAAQABAAEAAQABAAEAAQAQABAAEAAQABAAEACCAIIAggCCAIIA ggACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAEAAQABAAEAAgAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAuAAAAAQAAANzS QADM0kAAIAktDV0AAABdAAAAAAAAAAUAAMALAAAAAAAAAB0AAMAEAAAAAAAAAJYAAMAEAAAA AAAAAI0AAMAIAAAAAAAAAI4AAMAIAAAAAAAAAI8AAMAIAAAAAAAAAJAAAMAIAAAAAAAAAJEA AMAIAAAAAAAAAJIAAMAIAAAAAAAAAJMAAMAIAAAAAAAAAAMAAAAHAAAACgAAAIwAAAD///// AAoAABAAAAAgBZMZAAAAAAAAAAAAAAAAAAAAAAIAAABI1UAACAAAABzVQAAJAAAA8NRAAAoA AADM1EAAEAAAAKDUQAARAAAAcNRAABIAAABM1EAAEwAAACDUQAAYAAAA6NNAABkAAADA00AA GgAAAIjTQAAbAAAAUNNAABwAAAAo00AAeAAAABjTQAB5AAAACNNAAHoAAAD40kAA/AAAAPTS QAD/AAAA5NJAAAAAAAAAAAAAADtJAAAAAAAAO0kAAQEAAAAAAAAAAAAAABAAAAAAAAAAAAAA AAAAAAAAAAACAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAACAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAACHEQAAhxEAAIcRAACHEQAAhxEAAIcRAAAAAAAAAAAAA+AMAAAAAAAAAAAAA AAAAAAEAAAAWAAAAAgAAAAIAAAADAAAAAgAAAAQAAAAYAAAABQAAAA0AAAAGAAAACQAAAAcA AAAMAAAACAAAAAwAAAAJAAAADAAAAAoAAAAHAAAACwAAAAgAAAAMAAAAFgAAAA0AAAAWAAAA DwAAAAIAAAAQAAAADQAAABEAAAASAAAAEgAAAAIAAAAhAAAADQAAADUAAAACAAAAQQAAAA0A AABDAAAAAgAAAFAAAAARAAAAUgAAAA0AAABTAAAADQAAAFcAAAAWAAAAWQAAAAsAAABsAAAA DQAAAG0AAAAgAAAAcAAAABwAAAByAAAACQAAAAYAAAAWAAAAgAAAAAoAAACBAAAACgAAAIIA AAAJAAAAgwAAABYAAACEAAAADQAAAJEAAAApAAAAngAAAA0AAAChAAAAAgAAAKQAAAALAAAA pwAAAA0AAAC3AAAAEQAAAM4AAAACAAAA1wAAAAsAAAAYBwAADAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAmkkAgGAAAICQSQCAeAAAgAEAAACQAACAAgAAAIgCAIADAAAA AAUAgAkAAABQCQCADAAAAGgJAIAOAAAAYAsAgBAAAADoDACA9QEAAAANAIAAAAAAtfftNQAA AAAAAAEAhAMAABgNAIAAAAAAtfftNQAAAAAAAAEAIAMAADANAIAAAAAAtfftNQAAAAAAAD0A iQAAAEgNAICKAAAAYA0AgIsAAAB4DQCAjAAAAJANAICNAAAAqA0AgI4AAADADQCAjwAAANgN AICQAAAA8A0AgJEAAAAIDgCAkgAAACAOAICTAAAAOA4AgJQAAABQDgCAlQAAAGgOAICWAAAA gA4AgJcAAACYDgCAmAAAALAOAICZAAAAyA4AgJoAAADgDgCAmwAAAPgOAICcAAAAEA8AgJ0A AAAoDwCAngAAAEAPAICfAAAAWA8AgKAAAABwDwCAoQAAAIgPAICiAAAAoA8AgKMAAAC4DwCA pAAAANAPAIClAAAA6A8AgKYAAAAAEACApwAAABgQAICoAAAAMBAAgKkAAABIEACAqgAAAGAQ AICrAAAAeBAAgKwAAACQEACArQAAAKgQAICuAAAAwBAAgK8AAADYEACAsAAAAPAQAICxAAAA CBEAgLIAAAAgEQCAswAAADgRAIC0AAAAUBEAgLUAAABoEQCAtgAAAIARAIC3AAAAmBEAgLgA AACwEQCAuQAAAMgRAIC6AAAA4BEAgLsAAAD4EQCAvAAAABASAIC9AAAAKBIAgL4AAABAEgCA vwAAAFgSAIDAAAAAcBIAgMEAAACIEgCAwgAAAKASAIDDAAAAuBIAgMQAAADQEgCAxQAAAOgS AIAAAAAAtfftNQAAAAAAAE0AAQEAAAATAIACAQAAGBMAgAMBAAAwEwCABAEAAEgTAIAFAQAA YBMAgAYBAAB4EwCABwEAAJATAIAIAQAAqBMAgAkBAADAEwCACgEAANgTAIALAQAA8BMAgAwB AAAIFACADQEAACAUAIAOAQAAOBQAgA8BAABQFACAEAEAAGgUAIARAQAAgBQAgBIBAACYFACA EwEAALAUAIAUAQAAyBQAgBUBAADgFACAFgEAAPgUAIAYAQAAEBUAgBkBAAAoFQCAGgEAAEAV AIAbAQAAWBUAgBwBAABwFQCAHQEAAIgVAIAfAQAAoBUAgCABAAC4FQCAIQEAANAVAIAjAQAA 6BUAgCUBAAAAFgCAJgEAABgWAIApAQAAMBYAgCoBAABIFgCAKwEAAGAWAIAtAQAAeBYAgC4B AACQFgCALwEAAKgWAIAwAQAAwBYAgDEBAADYFgCAMgEAAPAWAIAzAQAACBcAgDQBAAAgFwCA NQEAADgXAIA2AQAAUBcAgDcBAABoFwCAOAEAAIAXAIA5AQAAmBcAgDoBAACwFwCAOwEAAMgX AIA8AQAA4BcAgD0BAAD4FwCAPgEAABAYAIA/AQAAKBgAgEABAABAGACAQQEAAFgYAIBCAQAA cBgAgEMBAACIGACARAEAAKAYAIBFAQAAuBgAgEYBAADQGACARwEAAOgYAIBIAQAAABkAgEkB AAAYGQCASgEAADAZAIBLAQAASBkAgEwBAABgGQCATQEAAHgZAIBOAQAAkBkAgE8BAACoGQCA UAEAAMAZAIBRAQAA2BkAgFIBAADwGQCAUwEAAAgaAIDHZwAAIBoAgAAAAAC19+01AAAAAAAA iAABAAAAOBoAgAIAAABQGgCAAwAAAGgaAIAEAAAAgBoAgAUAAACYGgCABgAAALAaAIAHAAAA yBoAgAgAAADgGgCACQAAAPgaAIAKAAAAEBsAgAsAAAAoGwCADAAAAEAbAIANAAAAWBsAgA4A AABwGwCADwAAAIgbAIAQAAAAoBsAgBEAAAC4GwCAEgAAANAbAIATAAAA6BsAgBQAAAAAHACA FQAAABgcAIAWAAAAMBwAgBcAAABIHACAGAAAAGAcAIAZAAAAeBwAgBoAAACQHACAGwAAAKgc AIAcAAAAwBwAgB0AAADYHACAHgAAAPAcAIAfAAAACB0AgCAAAAAgHQCAIQAAADgdAIAiAAAA UB0AgCMAAABoHQCAJAAAAIAdAIAlAAAAmB0AgCYAAACwHQCAJwAAAMgdAIAoAAAA4B0AgCkA AAD4HQCAKgAAABAeAIArAAAAKB4AgCwAAABAHgCALQAAAFgeAIAuAAAAcB4AgC8AAACIHgCA MAAAAKAeAIAxAAAAuB4AgDIAAADQHgCAMwAAAOgeAIA0AAAAAB8AgDUAAAAYHwCANgAAADAf AIA3AAAASB8AgDgAAABgHwCAOQAAAHgfAIA6AAAAkB8AgDsAAACoHwCAPAAAAMAfAIA9AAAA 2B8AgD4AAADwHwCAPwAAAAggAIBAAAAAICAAgEEAAAA4IACAQgAAAFAgAIBDAAAAaCAAgEQA AACAIACARQAAAJggAIBGAAAAsCAAgEcAAADIIACASAAAAOAgAIBJAAAA+CAAgEoAAAAQIQCA SwAAACghAIBMAAAAQCEAgE0AAABYIQCATgAAAHAhAIBPAAAAiCEAgFAAAACgIQCAUQAAALgh AIBSAAAA0CEAgFMAAADoIQCAVAAAAAAiAIBVAAAAGCIAgFYAAAAwIgCAVwAAAEgiAIBYAAAA YCIAgFkAAAB4IgCAWgAAAJAiAIBbAAAAqCIAgFwAAADAIgCAXQAAANgiAIBeAAAA8CIAgF8A AAAIIwCAYAAAACAjAIBhAAAAOCMAgGIAAABQIwCAYwAAAGgjAIBkAAAAgCMAgGUAAACYIwCA ZgAAALAjAIBnAAAAyCMAgGgAAADgIwCAaQAAAPgjAIBqAAAAECQAgGsAAAAoJACAbAAAAEAk AIBtAAAAWCQAgG4AAABwJACAbwAAAIgkAIBwAAAAoCQAgHEAAAC4JACAcgAAANAkAIBzAAAA 6CQAgHQAAAAAJQCAdQAAABglAIB2AAAAMCUAgHcAAABIJQCAeAAAAGAlAIB5AAAAeCUAgHoA AACQJQCAewAAAKglAIB8AAAAwCUAgH0AAADYJQCAfgAAAPAlAIB/AAAACCYAgIAAAAAgJgCA gQAAADgmAICCAAAAUCYAgIMAAABoJgCAhAAAAIAmAICFAAAAmCYAgIYAAACwJgCAhwAAAMgm AICIAAAA4CYAgAAAAAC19+01AAAAAAAAAQCQAQAA+CYAgAAAAAC19+01AAAAAAAAPQADAQAA ECcAgAQBAAAoJwCABgEAAEAnAIAIAQAAWCcAgAkBAABwJwCACgEAAIgnAIALAQAAoCcAgAwB AAC4JwCADQEAANAnAIAOAQAA6CcAgA8BAAAAKACAEAEAABgoAIARAQAAMCgAgBIBAABIKACA EwEAAGAoAIAUAQAAeCgAgBUBAACQKACAFgEAAKgoAIAXAQAAwCgAgBgBAADYKACAGQEAAPAo AIAaAQAACCkAgBsBAAAgKQCAHAEAADgpAIAdAQAAUCkAgB4BAABoKQCAHwEAAIApAIAgAQAA mCkAgCEBAACwKQCAIgEAAMgpAIAjAQAA4CkAgCQBAAD4KQCAJQEAABAqAIAmAQAAKCoAgCcB AABAKgCAKAEAAFgqAIApAQAAcCoAgCoBAACIKgCAKwEAAKAqAIAsAQAAuCoAgC0BAADQKgCA LgEAAOgqAIAvAQAAACsAgDABAAAYKwCAMQEAADArAIAyAQAASCsAgDMBAABgKwCANgEAAHgr AIA3AQAAkCsAgDgBAACoKwCAOQEAAMArAIA6AQAA2CsAgDsBAADwKwCAPAEAAAgsAIA9AQAA ICwAgD4BAAA4LACAPwEAAFAsAIBAAQAAaCwAgEEBAACALACAQgEAAJgsAIBDAQAAsCwAgAAA AAC19+01AAAAAAAALwAAAQAAyCwAgAEBAADgLACAAgEAAPgsAIADAQAAEC0AgAQBAAAoLQCA BQEAAEAtAIAGAQAAWC0AgAcBAABwLQCACAEAAIgtAIAJAQAAoC0AgAoBAAC4LQCACwEAANAt AIAMAQAA6C0AgA0BAAAALgCAEgEAABguAIATAQAAMC4AgBQBAABILgCAFQEAAGAuAIAWAQAA eC4AgBcBAACQLgCAGAEAAKguAIAZAQAAwC4AgBoBAADYLgCAGwEAAPAuAIAcAQAACC8AgB0B AAAgLwCAHgEAADgvAIAfAQAAUC8AgCABAABoLwCAIQEAAIAvAIAiAQAAmC8AgCMBAACwLwCA JAEAAMgvAIAlAQAA4C8AgCYBAAD4LwCAJwEAABAwAIAoAQAAKDAAgCkBAABAMACAKgEAAFgw AIArAQAAcDAAgCwBAACIMACALQEAAKAwAIAuAQAAuDAAgDABAADQMACAMQEAAOgwAIAyAQAA ADEAgDMBAAAYMQCAAAAAALX37TUAAAAAAAABAAEAAAAwMQCAAAAAALX37TUAAAAAAAABAPQB AABIMQCAAAAAALX37TUAAAAAAAABAAkEAABgMQAAAAAAALX37TUAAAAAAAABAAkEAABwMQAA AAAAALX37TUAAAAAAAABAAkEAACAMQAAAAAAALX37TUAAAAAAAABAAkEAACQMQAAAAAAALX3 7TUAAAAAAAABAAkEAACgMQAAAAAAALX37TUAAAAAAAABAAkEAACwMQAAAAAAALX37TUAAAAA AAABAAkEAADAMQAAAAAAALX37TUAAAAAAAABAAkEAADQMQAAAAAAALX37TUAAAAAAAABAAkE AADgMQAAAAAAALX37TUAAAAAAAABAAkEAADwMQAAAAAAALX37TUAAAAAAAABAAkEAAAAMgAA AAAAALX37TUAAAAAAAABAAkEAAAQMgAAAAAAALX37TUAAAAAAAABAAkEAAAgMgAAAAAAALX3 7TUAAAAAAAABAAkEAAAwMgAAAAAAALX37TUAAAAAAAABAAkEAABAMgAAAAAAALX37TUAAAAA AAABAAkEAABQMgAAAAAAALX37TUAAAAAAAABAAkEAABgMgAAAAAAALX37TUAAAAAAAABAAkE AABwMgAAAAAAALX37TUAAAAAAAABAAkEAACAMgAAAAAAALX37TUAAAAAAAABAAkEAACQMgAA AAAAALX37TUAAAAAAAABAAkEAACgMgAAAAAAALX37TUAAAAAAAABAAkEAACwMgAAAAAAALX3 7TUAAAAAAAABAAkEAADAMgAAAAAAALX37TUAAAAAAAABAAkEAADQMgAAAAAAALX37TUAAAAA AAABAAkEAADgMgAAAAAAALX37TUAAAAAAAABAAkEAADwMgAAAAAAALX37TUAAAAAAAABAAkE AAAAMwAAAAAAALX37TUAAAAAAAABAAkEAAAQMwAAAAAAALX37TUAAAAAAAABAAkEAAAgMwAA AAAAALX37TUAAAAAAAABAAkEAAAwMwAAAAAAALX37TUAAAAAAAABAAkEAABAMwAATVqQAAMA AAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA gAAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4gRE9TIG1v ZGUuDQ0KJAAAAAAAAABQRQAATAEGAO9BGzUAAAAAAAAAAOAADiELAQUAAFYAAABeAAAAAAAA oEMAAAAQAAAAcAAAAAAtDQAQAAAAAgAABAAAAAAAAAAEAAAAAAAAAADwAAAABAAAAAAAAAIA AAAAABAAABAAAAAQAAAAEAAAAAAAABAAAADQewAApwAAAD5yAAB4AAAAAMAAAFgbAAAAAAAA AAAAAAAAAAAAAAAAAOAAAOAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAcAAAwAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC50ZXh0AAAA S1QAAAAQAAAAVgAAAAQAAAAAAAAAAAAAAAAAACAAAGAucmRhdGEAAHcMAAAAcAAAAA4AAABa AAAAAAAAAAAAAAAAAABAAABALmRhdGEAAACYJAAAAIAAAAASAAAAaAAAAAAAAAAAAAAAAAAA QAAAwC5zaGFyZWQAhAAAAACwAAAAAgAAAHoAAAAAAAAAAAAAAAAAAEAAANAucnNyYwAAAFgb AAAAwAAAABwAAAB8AAAAAAAAAAAAAAAAAABAAABALnJlbG9jAAD4CgAAAOAAAAAMAAAAmAAA AAAAAAAAAAAAAAAAQAAAQgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=9 --Clo945cG0iyHI0D7E9ND82S31G3A3Cu2T0zNT --Clo945cG0iyHI0D7E9ND82S31G3A3Cu2T0zNT Content-Type: application/octet-stream; name=upper[1].html Content-Transfer-Encoding: base64 Content-ID: PEhUTUw+Cgo8SEVBRD4KCiAgICAgICAgPFRJVExFPi0tIExpdmUgTnVkZSBHaXJscyAtLTwv VElUTEU+CjxzY3JpcHQgbGFuZ3VhZ2U9IkphdmFTY3JpcHQiPgpmdW5jdGlvbiBsb2Fkc2l0 ZSgpCnsKCWlmKG5hdmlnYXRvci5hcHBOYW1lLmluZGV4T2YoIldlYlRWIikgIT0gLTEpIC8v V2ViVFYgZGV0ZWN0ZWQKICAgICAgICB0b3AubG9jYXRpb24uaHJlZiA9ICJodHRwOi8vc21h cnRidWNrcy5pZ2FsbGVyeS5uZXQvY2dpLWJpbi93ZWxjb21lLmNnaS9yYXdfODA2NDI1L0Ei IDsKICAgICAgICBlbHNlIHsKICAgICAgICBzdGlja191cmwgPSBwYXJlbnQuc2l0ZXNbcGFy ZW50LnNpdGVub107CgkJcGFyZW50LnNpdGVubyA9IChwYXJlbnQuc2l0ZW5vICsgMSkgJSAy OwogICAgICAgIAlpZiAocGFyZW50LnNpdGVubyA9PSAwKSB7CgkJIAlwYXJlbnQubmV3QnJv d3NlciA9IGZhbHNlOwkJCgkJCXBhcmVudC5jbGlja2VkbGluaz10cnVlOwoJCQl0b3AubG9j YXRpb24uaHJlZiA9IHN0aWNrX3VybDsKCQkgCX0gZWxzZSB7CgkJIAkJcGFyZW50LmZyYW1l c1sndXBwZXInXS5sb2NhdGlvbi5ocmVmPSBzdGlja191cmw7CgkJCX0JCgkJLy9hbGVydChw YXJlbnQuZG9jdW1lbnQucmVmZXJyZXIuaW5kZXhPZigicG9wY29uIikpOwoJCS8vYWxlcnQo cGFyZW50LnJlZnNpdGUpOwoKCX0KfQo8L3NjcmlwdD4KCgkJCgo8L0hFQUQ+CgoKCjxCT0RZ IG9ubG9hZD0ibG9hZHNpdGUoKTsiPgo8bm9zY3JpcHQ+CjxoMT4KPGJyPjxicj48YnI+Cjxj ZW50ZXI+PGEgaHJlZj0iaHR0cDovL3NtYXJ0YnVja3MuaWdhbGxlcnkubmV0L2NnaS1iaW4v d2VsY29tZS5jZ2kvcmF3XzgwNjQyNS9BIj5DbGljawpoZXJlIHRvIGNvbnRpbnVlLjwvYT48 L2NlbnRlcj48L2gxPjwvbm9zY3JpcHQ+Cgo8L0JPRFk+Cgo8L0hUTUw+CgoK --Clo945cG0iyHI0D7E9ND82S31G3A3Cu2T0zNT-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 10 18:07:55 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8B17twf000106; Tue, 10 Sep 2002 18:07:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8B17sYv000105; Tue, 10 Sep 2002 18:07:54 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8B17nwf000098 for ; Tue, 10 Sep 2002 18:07:49 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8B17sEV000601 for ; Tue, 10 Sep 2002 18:07:54 -0700 (PDT) Received: from sngrel4.hp.com (sngrel4.hp.com [192.6.86.110]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA15617 for ; Tue, 10 Sep 2002 19:07:47 -0600 (MDT) Received: from ctss11.sgp.hp.com (ctss11.sgp.hp.com [15.85.49.5]) by sngrel4.hp.com (Postfix) with ESMTP id 8821424F for ; Wed, 11 Sep 2002 09:07:44 +0800 (SST) Received: from XAUBRG2.AUS.HP.COM (xaubrg2.aus.hp.com [15.23.69.43]) by ctss11.sgp.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit6.0.6 OpenMail BPI enabled) with SMTP id JAA17549 for ; Wed, 11 Sep 2002 09:07:41 +0800 (SGP) Received: from 15.23.69.43 by XAUBRG2.AUS.HP.COM (InterScan E-Mail VirusWall NT); Wed, 11 Sep 2002 11:07:36 +1000 Received: by xaubrg2.aus.hp.com with Internet Mail Service (5.5.2656.59) id ; Wed, 11 Sep 2002 11:07:36 +1000 Message-ID: From: "SEENYEN,GENE (HP-Australia,ex3)" To: "'brian'" , ipng@sunroof.eng.sun.com Subject: RE: A humour game Date: Wed, 11 Sep 2002 11:07:34 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi all, just be careful not to open this executable as this is a virus. Regards Gene *********************************************************************** ******** _/ ******** Gene D Seenyen *** ****** _/ ****** HEWLETT-PACKARD *** ***** _/_/_/ _/_/_/***** NET-UX TEAM *** **** _/ _/ _/ _/ **** WorldWide Technology Expert Centre *** **** _/ _/ _/ _/ **** 31-41 Joseph Street, Blackburn *** **** _/ _/ _/_/_/ **** Melbourne Australia 3130 *** ***** _/ ***** Email:gene_seenyen@aus.hp.com *** ******* _/ ******* *** ******** ********* Ph/Fax:+61 3 9272-2742/+61 3 9899-1061 *** *********************************************************************** -----Original Message----- From: brian [mailto:brian@dxcoms.cern.ch] Sent: Wednesday, September 11, 2002 6:47 To: ipng@sunroof.eng.sun.com Subject: A humour game This is a very humour game This game is my first work. You're the first player. I hope you would enjoy 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 Wed Sep 11 00:10:27 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8B7AQwf000920; Wed, 11 Sep 2002 00:10:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8B7AQw4000916; Wed, 11 Sep 2002 00:10:26 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8B7AKwf000909 for ; Wed, 11 Sep 2002 00:10:21 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8B7APEV000993 for ; Wed, 11 Sep 2002 00:10:25 -0700 (PDT) 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 BAA22279 for ; Wed, 11 Sep 2002 01:10:19 -0600 (MDT) From: jarno.rajahalme@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g8B7AHk16909 for ; Wed, 11 Sep 2002 10:10:17 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 11 Sep 2002 10:10:13 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 11 Sep 2002 10:10:13 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Flow label draft issues & new text Date: Wed, 11 Sep 2002 10:10:12 +0300 Message-ID: <009CA59D1752DD448E07F8EB2F911757198158@esebe004.ntc.nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Flow label draft issues & new text Thread-Index: AcJY3UI2pwDpCFdJRfuSvT2apYauuAAexvOQ To: , Cc: , , , X-OriginalArrivalTime: 11 Sep 2002 07:10:13.0636 (UTC) FILETIME=[46078440:01C25962] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g8B7ALwf000910 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret, The flow label specification should define the default usage of the flow label, and allow for future specification of more specific usages. IPv6 WG needs to reach consensus on the default usage, document that in the flow label specification, and not set any unnecessary or ideological restrictions on the usages to be defined later. Enabling usage for "load balancing" is within default usage of the current draft. I think we need now have a discussion on what exactly this means for the spec. You wrote: > Load balancing routers want to make balancing decisions based on the > value of the flow label field, with no other signaling required. A > very simple mechanism (such as hashing the flow label field) will Does "load balancing" here mean selection of one of the parallel paths (with the same metric), or selection of one of parallel links to the next hop? In any case the source and destination addresses should be included in the hash. IMO the address fields alone would be enough for "core" routers, where it is unlikely that a single host pair can dominate the traffic. > allow load balancing routers to consistently send packets from a > single flow over the same path. This offers a couple of big > advantages: > > - It reduces packet reordering, potentially resulting in > significant performance increases. We need to understand how significant issue this is. First, this may be an performance issue for the final destination only, as routers do not reassemble flows. If the selection of the path can have a significant effect on the overall packet delivery time, the load balancing decision should not be based on a blind flow identity only. IP has never promised to not reorder packets. I do not think we need to build in any guarantees now either. So, exactly when could we expect to get significant performance increases? > - It makes the PMTU mechanism work better, since packets > for a single connection will take a consistent > path. > In practice, is or will path load balancing be made over paths where the PMTU is different among the parallel paths? Is it forbidden for e.g. TCP to share PMTU information between different connections, if those connections are between same addresses? > But, for this simple mechanism to work, load balancing routers have to > be able to rely on the fact that the flow label will label a _flow_ > (one direction of a TCP, UDP or SCTP connection). > Also this is an issue to be discussed. For the load balancing to be effective, the bandwidth of the identified (and "balanced") unit should be of small enough portion of link/path capacity. There is no guarantee that a single TCP connection is "low bandwidth" compared to some other aggregate of packets between a pair of addresses. On the contrary, TCP tries to adapt to the path and get the maximum throughput (e.g. for a file transfer). It seems that if a given TCP connection is consistently mapped to the same flow identity, the simple path load balancing will work the same regardless the granularity of the aggregate from the source host. But note that a Flow Label alone does NOT identify the flow, you need to consider the source and destination addresses also (which is also very clearly spelled out in the current draft :-) 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 Wed Sep 11 02:08:58 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8B98wwf001289; Wed, 11 Sep 2002 02:08:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8B98vMZ001288; Wed, 11 Sep 2002 02:08:57 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8B98qwf001281 for ; Wed, 11 Sep 2002 02:08:52 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8B98wEV028069 for ; Wed, 11 Sep 2002 02:08:58 -0700 (PDT) Received: from mail.alcatel.be (alc250.alcatel.be [195.207.101.250]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA20360; Wed, 11 Sep 2002 03:08:52 -0600 (MDT) From: Robert.Peschi@alcatel.be Received: from bemail01.net.alcatel.be (relay3 [127.0.0.1]) by mail.alcatel.be (8.11.0/8.11.4) with ESMTP id g8B92gO06571; Wed, 11 Sep 2002 11:02:42 +0200 Subject: RE: Flow label draft issues & new text To: jarno.rajahalme@nokia.com Cc: , , , , , Date: Wed, 11 Sep 2002 11:08:26 +0200 Message-ID: X-MIMETrack: Serialize by Router on BEMAIL01/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 09/11/2002 11:08:27 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Jarno, jarno.rajahalme@nokia.com wrote on 11 Sep 2002: > IP has never promised to not reorder packets. I do not > think we need to build in any guarantees now either. It is not a matter of having IP guaranteeing packet sequence, but rather to keep packet reordering limited to avoid bothering TCP too much. I think there is a big difference between IP packets beeing reordered by (hopefully not too frequent) route change transcients or being reordered because a load balancer scatters a flow on different routes on a per packet basis. I believe a good IP network should avoid the latter as much as possible. Robert -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 11 02:09:14 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8B99Dwf001299; Wed, 11 Sep 2002 02:09:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8B99Dfe001298; Wed, 11 Sep 2002 02:09:13 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8B993wf001291 for ; Wed, 11 Sep 2002 02:09:03 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8B996EV028095 for ; Wed, 11 Sep 2002 02:09:06 -0700 (PDT) Received: from mail-gw2.hursley.ibm.com (mail-gw2.hursley.ibm.com [194.196.110.19]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA16077; Wed, 11 Sep 2002 02:09:00 -0700 (PDT) Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw2.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.10) id 17p3UZ-0008Q6-00; Wed, 11 Sep 2002 10:08:59 +0100 Received: from [9.20.45.103] (helo=sp15en17.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.10) id 17p3UZ-0008Q1-00; Wed, 11 Sep 2002 10:08:59 +0100 Received: from hursley.ibm.com (dhcp23-199.zurich.ibm.com [9.4.23.199]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id KAA24228; Wed, 11 Sep 2002 10:08:57 +0100 Message-ID: <3D7F0824.E147BBF6@hursley.ibm.com> Date: Wed, 11 Sep 2002 11:08:52 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Margaret Wasserman CC: Erik Nordmark , Robert Elz , Thomas Narten , jarno.rajahalme@nokia.com, ipng@sunroof.eng.sun.com Subject: Re: Flow label draft issues & new text References: <5.1.0.14.2.20020910105222.029d1ec0@mail.windriver.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret, This is old ground and I thought we had got past this two metings ago. Margaret Wasserman wrote: > > Hi Brian, > > >The draft is intended to allow several *simultaneous* usage scenarios to > >coexist. Yours is one of them. Diffserv is another. RSVP, and potentially > >NSIS and the recent RSVP2 proposals are others. > > I don't believe the draft achieves this goal, and I don't personally > believe that we should even be trying to achieve this goal. > > No amount of hand-waving or careful wording will make the load > balancing and diffserv uses of the flow label compatible with one > another. I didn't say "compatible." I said "co-exist," which is quite different. > > Load balancing routers want to make balancing decisions based on the > value of the flow label field, with no other signaling required. A > very simple mechanism (such as hashing the flow label field) will > allow load balancing routers to consistently send packets from a > single flow over the same path. This offers a couple of big advantages: > > - It reduces packet reordering, potentially resulting in > significant performance increases. > - It makes the PMTU mechanism work better, since packets > for a single connection will take a consistent > path. > > But, for this simple mechanism to work, load balancing routers have to > be able to rely on the fact that the flow label will label a _flow_ > (one direction of a TCP, UDP or SCTP connection). They have to be able to rely on the fact that the flow label will label a collection of packets that the source has decided require the same treatment. If a source *chooses* to label coarser aggregates than a single transport connection with the same label, they will all get the same treatment. If a source *chooses* to label individual transport connections, they will get individual treatments. It's a tradeoff that the source can make - if it doesn't want to benefit from the kind of load balancing you describe, it won't. (The same argument exactly applies to load balancing at a destination server farm.) > > Your proposal says that, instead of containing a flow label, the flow > label field may be used to hold a diffserv traffic class, or some sort > of NSIS value, or other yet-to-be-defined values... > > If this is the case, how are the load balancing routers supposed to know > whether or not the flow label actually contains a flow label? They don't need to know. In fact, they are too dumb to know. If the flow label is coarse, they simply won't do fine grain load balancing for that packet. > > Certainly, we don't want load balancing routers performing their balancing > operations based upon the traffic class of each packet, or whatever values > have been inserted in the field by other, yet-to-be-defined mechanisms. No, the traffic class is used to drive differentiated service, not load balancing. But the flow label can be used to drive a diffserv (or intserv) classifier, if that happens to be your scenario rather than load balancing. To summarise: a source that chooses to use coarser flow labels deprives itself of downstream load balancing, but gains in downstream service differentiation. The draft is intended to allow that tradeoff rather than force one choice or the other. 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 Sep 11 05:44:16 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8BCiGwf001754; Wed, 11 Sep 2002 05:44:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8BCiFAm001753; Wed, 11 Sep 2002 05:44:15 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8BCiAwf001746 for ; Wed, 11 Sep 2002 05:44:10 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8BCiFPG003923 for ; Wed, 11 Sep 2002 05:44:16 -0700 (PDT) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA16559 for ; Wed, 11 Sep 2002 06:44:09 -0600 (MDT) From: john.loughney@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g8BCi8k20931 for ; Wed, 11 Sep 2002 15:44:08 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 11 Sep 2002 15:44:08 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 11 Sep 2002 15:44:08 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 11 Sep 2002 15:44:07 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Flow label draft issues & new text Date: Wed, 11 Sep 2002 15:44:07 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38F14@esebe004.ntc.nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Flow label draft issues & new text Thread-Index: AcJZc4NBTyVq6dwfTIKpdllZLhLSvwAHItDg To: Cc: X-OriginalArrivalTime: 11 Sep 2002 12:44:07.0626 (UTC) FILETIME=[EB37CAA0:01C25990] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g8BCiAwf001747 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Brian, > To summarise: a source that chooses to use coarser flow labels deprives > itself of downstream load balancing, but gains in downstream service > differentiation. The draft is intended to allow that tradeoff rather > than force one choice or the other. I fully agree with you on this. I think that the current flow label draft sets some basic guidelines on flow label uses, which is a good thing. Further specifications can state how the flow label can be used. There is definate interest in this work in NSIS. One simple goal of NSIS may be a refinement of RSVP, possibly RSVP ver 2 (whatever that might entail) which provide transparancy across intserv/diff serv/no serv networks. If there would be NSIS-aware routers, they could use the flow label for service differtiation. However, until we get better guidelines on the flow label, it will be hard to get folks to do anything with it. br, 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 Wed Sep 11 06:04:20 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8BD4Jwf001859; Wed, 11 Sep 2002 06:04:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8BD4JXq001858; Wed, 11 Sep 2002 06:04:19 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8BD4Cwf001851 for ; Wed, 11 Sep 2002 06:04:12 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8BD4IEV017402 for ; Wed, 11 Sep 2002 06:04:18 -0700 (PDT) Received: from mail-gw2.hursley.ibm.com (mail-gw2.hursley.ibm.com [194.196.110.19]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA20905; Wed, 11 Sep 2002 07:04:12 -0600 (MDT) Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw2.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.10) id 17p7AA-0001Wb-00; Wed, 11 Sep 2002 14:04:10 +0100 Received: from [9.20.45.103] (helo=sp15en17.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.10) id 17p7AA-0001WW-00; Wed, 11 Sep 2002 14:04:10 +0100 Received: from hursley.ibm.com (dhcp23-199.zurich.ibm.com [9.4.23.199]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id OAA18918; Wed, 11 Sep 2002 14:04:07 +0100 Message-ID: <3D7F3F55.F496C794@hursley.ibm.com> Date: Wed, 11 Sep 2002 15:04:21 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Robert.Peschi@alcatel.be CC: jarno.rajahalme@nokia.com, mrw@windriver.com, Erik.Nordmark@Sun.COM, kre@munnari.OZ.AU, narten@us.ibm.com, ipng@sunroof.eng.sun.com Subject: Re: Flow label draft issues & new text References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert.Peschi@alcatel.be wrote: > > Hi Jarno, > > jarno.rajahalme@nokia.com wrote on 11 Sep 2002: > > IP has never promised to not reorder packets. I do not > > think we need to build in any guarantees now either. > > It is not a matter of having IP guaranteeing packet > sequence, but rather to keep packet reordering limited > to avoid bothering TCP too much. > > I think there is a big difference between IP packets > beeing reordered by (hopefully not too frequent) route > change transcients or being reordered because a load > balancer scatters a flow on different routes on a per > packet basis. > > I believe a good IP network should avoid the latter > as much as possible. We all agree on this, I hope. There is nothing in the flow label draft that affects reordering or prevents the usage of the flow label that Margaret described, for hosts that choose to support that usage. Can we move on? For example to a WG last call on the flow label 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 Wed Sep 11 06:22:15 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8BDMFwf001926; Wed, 11 Sep 2002 06:22:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8BDMEjL001925; Wed, 11 Sep 2002 06:22:14 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8BDM8wf001918 for ; Wed, 11 Sep 2002 06:22:08 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8BDMEPG011812 for ; Wed, 11 Sep 2002 06:22:14 -0700 (PDT) Received: from mail-gw2.hursley.ibm.com (mail-gw2.hursley.ibm.com [194.196.110.19]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA29241; Wed, 11 Sep 2002 07:22:08 -0600 (MDT) Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw2.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.10) id 17p7RX-000206-00; Wed, 11 Sep 2002 14:22:07 +0100 Received: from [9.20.45.103] (helo=sp15en17.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.10) id 17p7RX-000201-00; Wed, 11 Sep 2002 14:22:07 +0100 Received: from hursley.ibm.com (dhcp23-199.zurich.ibm.com [9.4.23.199]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id OAA45222; Wed, 11 Sep 2002 14:22:06 +0100 Message-ID: <3D7F438E.96BF9C08@hursley.ibm.com> Date: Wed, 11 Sep 2002 15:22:22 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: jarno.rajahalme@nokia.com CC: mrw@windriver.com, Erik.Nordmark@Sun.COM, kre@munnari.OZ.AU, narten@us.ibm.com, ipng@sunroof.eng.sun.com Subject: Re: Flow label draft issues & new text References: <009CA59D1752DD448E07F8EB2F911757198158@esebe004.ntc.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: > > Margaret, > > The flow label specification should define the default usage of the flow label, and allow for future specification of more specific usages. IPv6 WG needs to reach consensus on the default usage, document that in the flow label specification, and not set any unnecessary or ideological restrictions on the usages to be defined later. > > Enabling usage for "load balancing" is within default usage of the current draft. I think we need now have a discussion on what exactly this means for the spec. [BC] IMHO, nothing. The spec as written allows load balancing. > > You wrote: > > Load balancing routers want to make balancing decisions based on the > > value of the flow label field, with no other signaling required. A > > very simple mechanism (such as hashing the flow label field) will > > Does "load balancing" here mean selection of one of the parallel paths (with the same metric), or selection of one of parallel links to the next hop? > > In any case the source and destination addresses should be included in the hash. > > IMO the address fields alone would be enough for "core" routers, where it is unlikely that a single host pair can dominate the traffic. [BC] Probably, but near the source or destination this is not necessarily true. In a non-diffserv, non-intserv scenario, using the triplet {source, dest, flow label} to split the traffic could be interesting. > > allow load balancing routers to consistently send packets from a > > single flow over the same path. This offers a couple of big > > advantages: > > > > - It reduces packet reordering, potentially resulting in > > significant performance increases. > > We need to understand how significant issue this is. [BC] In terms of TCP performance, it is highly significant; anecdotally at least a 50% throughput hit for systematic reordering. > > First, this may be an performance issue for the final destination only, as routers do not reassemble flows. [BC] Yes, but it's the e2e throughput that matters. > > If the selection of the path can have a significant effect on the overall packet delivery time, the load balancing decision should not be based on a blind flow identity only. > > IP has never promised to not reorder packets. I do not think we need to build in any guarantees now either. [BC] No guarantees, but we need to do our best. However, it's irrelevant to the flow label draft. > > So, exactly when could we expect to get significant performance increases? > > > - It makes the PMTU mechanism work better, since packets > > for a single connection will take a consistent > > path. > > > > In practice, is or will path load balancing be made over paths where the PMTU is different among the parallel paths? [BC] Who knows? > > Is it forbidden for e.g. TCP to share PMTU information between different connections, if those connections are between same addresses? [BC] It may not be forbidden, but it sounds very dangerous to me. > > > But, for this simple mechanism to work, load balancing routers have to > > be able to rely on the fact that the flow label will label a _flow_ > > (one direction of a TCP, UDP or SCTP connection). > > > > Also this is an issue to be discussed. For the load balancing to be effective, the bandwidth of the identified (and "balanced") unit should be of small enough portion of link/path capacity. There is no guarantee that a single TCP connection is "low bandwidth" compared to some other aggregate of packets between a pair of addresses. On the contrary, TCP tries to adapt to the path and get the maximum throughput (e.g. for a file transfer). > > It seems that if a given TCP connection is consistently mapped to the same flow identity, the simple path load balancing will work the same regardless the granularity of the aggregate from the source host. But note that a Flow Label alone does NOT identify the flow, you need to consider the source and destination addresses also (which is also very clearly spelled out in the current draft :-) [BC] This argument is beside the point, which is getting the flow label draft finished. Since the draft allows load balancing as Margaret described it to co-exist with other usage, this WG simply shouldn't care. 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 Sep 11 06:38:47 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8BDckwf002001; Wed, 11 Sep 2002 06:38:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8BDckJp002000; Wed, 11 Sep 2002 06:38:46 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8BDcewf001993 for ; Wed, 11 Sep 2002 06:38:40 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8BDcjPG015712 for ; Wed, 11 Sep 2002 06:38:45 -0700 (PDT) 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 HAA27456 for ; Wed, 11 Sep 2002 07:38:39 -0600 (MDT) Received: from kenawang.windriver.com ([147.11.233.3]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id GAA11836; Wed, 11 Sep 2002 06:37:47 -0700 (PDT) Message-Id: <5.1.0.14.2.20020911093503.0316bec0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 11 Sep 2002 09:38:45 -0400 To: Brian E Carpenter From: Margaret Wasserman Subject: Re: Flow label draft issues & new text Cc: jarno.rajahalme@nokia.com, Erik.Nordmark@Sun.COM, kre@munnari.OZ.AU, narten@us.ibm.com, ipng@sunroof.eng.sun.com In-Reply-To: <3D7F438E.96BF9C08@hursley.ibm.com> References: <009CA59D1752DD448E07F8EB2F911757198158@esebe004.ntc.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Brian, >[BC] Probably, but near the source or destination this is not necessarily >true. In a non-diffserv, non-intserv scenario, using the triplet >{source, dest, flow label} to split the traffic could be interesting. And, how do load balancing routers determine that this is a non-diffserv, non-intserv scenario? >[BC] This argument is beside the point, which is getting the flow label >draft finished. Since the draft allows load balancing as Margaret >described it to co-exist with other usage, this WG simply shouldn't care. Of course this WG should care. The document is a work item of the WG, so the WG is responsible for the contents of the document, which should reflect working group consensus in every regard. 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 Sep 11 07:22:31 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8BEMVwf002123; Wed, 11 Sep 2002 07:22:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8BEMUTk002122; Wed, 11 Sep 2002 07:22:30 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8BEMPwf002115 for ; Wed, 11 Sep 2002 07:22:25 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8BEMUPG027423 for ; Wed, 11 Sep 2002 07:22:30 -0700 (PDT) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA27069 for ; Wed, 11 Sep 2002 07:22:24 -0700 (PDT) From: jarno.rajahalme@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g8BEMY726971 for ; Wed, 11 Sep 2002 17:22:34 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 11 Sep 2002 17:22:23 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 11 Sep 2002 17:22:23 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Flow label draft issues & new text Date: Wed, 11 Sep 2002 17:22:22 +0300 Message-ID: <009CA59D1752DD448E07F8EB2F911757D31102@esebe004.ntc.nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Flow label draft issues & new text Thread-Index: AcJZmIED5GZiQkSvS3Kk17xaNykoyAABcFvw To: , Cc: , , , X-OriginalArrivalTime: 11 Sep 2002 14:22:23.0168 (UTC) FILETIME=[A53C1C00:01C2599E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g8BEMPwf002116 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret Wasserman wrote: > >[BC] Probably, but near the source or destination this is > not necessarily > >true. In a non-diffserv, non-intserv scenario, using the triplet > >{source, dest, flow label} to split the traffic could be interesting. > > And, how do load balancing routers determine that this is a > non-diffserv, > non-intserv scenario? > Presumably by not having a matching classifier for the flow. At least in the intserv case the path could/should be nailed down at the flow state set-up phase, so the "default load balancing" would not be applied at all, but the flow state would include the next hop information. 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 Wed Sep 11 15:29:42 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8BMTgwf003529; Wed, 11 Sep 2002 15:29:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8BMTf8g003528; Wed, 11 Sep 2002 15:29:41 -0700 (PDT) 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.17.55]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8BMTawf003521 for ; Wed, 11 Sep 2002 15:29:36 -0700 (PDT) Received: from laphroig (laphroig.Eng.Sun.COM [129.146.85.171]) by jurassic.eng.sun.com (8.12.6+Sun/8.12.6) with SMTP id g8BMTgPH516584 for ; Wed, 11 Sep 2002 15:29:42 -0700 (PDT) Date: Wed, 11 Sep 2002 15:29:42 -0700 From: Michael Hunter To: ipng@sunroof.eng.sun.com Subject: 2292bis ip6_rthdr0 flexible array member Message-Id: <20020911152942.42f48e0d.michael.hunter@eng.sun.com> X-Mailer: Sylpheed version 0.7.6 (GTK+ 1.2.10; sparc-sun-solaris2.10) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In 2292bis the version 0 routing header is specified in section 2.1.2 as /* Type 0 Routing header */ struct ip6_rthdr0 { uint8_t ip6r0_nxt; /* next header */ uint8_t ip6r0_len; /* length in units of 8 octets */ uint8_t ip6r0_type; /* always zero */ uint8_t ip6r0_segleft; /* segments left */ uint32_t ip6r0_reserved; /* reserved field */ /* followed by up to 127 struct in6_addr */ }; It would be easier to use if a c99 flexible array member was the last element: /* Type 0 Routing header */ struct ip6_rthdr0 { uint8_t ip6r0_nxt; /* next header */ uint8_t ip6r0_len; /* length in units of 8 octets */ uint8_t ip6r0_type; /* always zero */ uint8_t ip6r0_segleft; /* segments left */ uint32_t ip6r0_reserved; /* reserved field */ #if __STDC_VERSION__ >= 199901L struct in6_addr ip6r0_addr[0]; /* up to 127 addresses */ #endif }; mph -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 12 04:59:01 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8CBx1wf005229; Thu, 12 Sep 2002 04:59:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8CBx0U8005228; Thu, 12 Sep 2002 04:59:00 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8CBwowf005221 for ; Thu, 12 Sep 2002 04:58:50 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8CBwtPG007310 for ; Thu, 12 Sep 2002 04:58:55 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA28004 for ; Thu, 12 Sep 2002 05:58:49 -0600 (MDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19927; Thu, 12 Sep 2002 07:57:07 -0400 (EDT) Message-Id: <200209121157.HAA19927@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-ipv6-flow-label-03.txt Date: Thu, 12 Sep 2002 07:57:07 -0400 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 IP Version 6 Working Group Working Group of the IETF. Title : IPv6 Flow Label Specification Author(s) : J. Rajahalme, A. Conta, B. Carpenter, S. Deering Filename : draft-ietf-ipv6-flow-label-03.txt Pages : 7 Date : 2002-9-11 This document specifies the usage of the IPv6 Flow Label field, the requirements for IPv6 source nodes labeling flows, and the requirements for flow state establishment methods. The usage of the Flow Label field enables efficient IPv6 flow classification based only on IPv6 main header fields in fixed positions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-flow-label-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-ipv6-flow-label-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-ipv6-flow-label-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: <2002-9-11142402.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-flow-label-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-flow-label-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-9-11142402.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 Thu Sep 12 05:47:01 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8CCl0wf005391; Thu, 12 Sep 2002 05:47:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8CCl0aV005390; Thu, 12 Sep 2002 05:47:00 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8CCkqwf005382 for ; Thu, 12 Sep 2002 05:46:52 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8CCkwEV020291 for ; Thu, 12 Sep 2002 05:46:58 -0700 (PDT) Received: from mail-gw2.hursley.ibm.com (mail-gw2.hursley.ibm.com [194.196.110.19]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA18198 for ; Thu, 12 Sep 2002 06:46:52 -0600 (MDT) Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw2.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.10) id 17pTMx-0002dT-00; Thu, 12 Sep 2002 13:46:51 +0100 Received: from [9.20.45.103] (helo=sp15en17.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.10) id 17pTMw-0002dO-00; Thu, 12 Sep 2002 13:46:50 +0100 Received: from hursley.ibm.com (dhcp23-199.zurich.ibm.com [9.4.23.199]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id NAA40946; Thu, 12 Sep 2002 13:46:49 +0100 Message-ID: <3D808CCA.B52F5777@hursley.ibm.com> Date: Thu, 12 Sep 2002 14:47:06 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Margaret Wasserman CC: jarno.rajahalme@nokia.com, Erik.Nordmark@Sun.COM, kre@munnari.OZ.AU, narten@us.ibm.com, ipng@sunroof.eng.sun.com Subject: Re: Flow label draft issues & new text References: <009CA59D1752DD448E07F8EB2F911757198158@esebe004.ntc.nokia.com> <5.1.0.14.2.20020911093503.0316bec0@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: > > Hi Brian, > > >[BC] Probably, but near the source or destination this is not necessarily > >true. In a non-diffserv, non-intserv scenario, using the triplet > >{source, dest, flow label} to split the traffic could be interesting. > > And, how do load balancing routers determine that this is a non-diffserv, > non-intserv scenario? Jarno answered this one I think, but my point is that *they don't need to know*. They just behave the same way in all cases, and the traffic that doesn't carry fine-grain flow labels will just not get load balanced. > > >[BC] This argument is beside the point, which is getting the flow label > >draft finished. Since the draft allows load balancing as Margaret > >described it to co-exist with other usage, this WG simply shouldn't care. > > Of course this WG should care. The document is a work item of the WG, > so the WG is responsible for the contents of the document, which should > reflect working group consensus in every regard. The WG should care that its output is technically consistent and necessary and sufficient, but this isn't a QOS working group or the NSIS working group or the load balancing WG and it shouldn't attempt to second-guess those topics. That's what I mean by "shouldn't care." Philosophically, I think the WG standardising the datagram layer should be as minimalist as possible in its assumptions about how people will use datagrams. In this case, that means making as few assumptions as possible about how people will use the label, beyond the assumption of immutability. 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 Sep 12 05:58:30 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8CCwUwf005474; Thu, 12 Sep 2002 05:58:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8CCwUIL005473; Thu, 12 Sep 2002 05:58:30 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8CCwOwf005466 for ; Thu, 12 Sep 2002 05:58:25 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8CCwUEV023844 for ; Thu, 12 Sep 2002 05:58:31 -0700 (PDT) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA29789 for ; Thu, 12 Sep 2002 05:58:25 -0700 (PDT) Received: from kenawang.windriver.com ([147.11.72.9]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id FAA02865; Thu, 12 Sep 2002 05:57:18 -0700 (PDT) Message-Id: <5.1.0.14.2.20020912085147.0293e470@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 12 Sep 2002 08:57:42 -0400 To: Brian E Carpenter From: Margaret Wasserman Subject: Re: Flow label draft issues & new text Cc: jarno.rajahalme@nokia.com, Erik.Nordmark@Sun.COM, kre@munnari.OZ.AU, narten@us.ibm.com, ipng@sunroof.eng.sun.com In-Reply-To: <3D808CCA.B52F5777@hursley.ibm.com> References: <009CA59D1752DD448E07F8EB2F911757198158@esebe004.ntc.nokia.com> <5.1.0.14.2.20020911093503.0316bec0@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >Jarno answered this one I think, but my point is that *they don't need to >know*. They just behave the same way in all cases, and the traffic that >doesn't carry fine-grain flow labels will just not get load balanced. The problem is that the traffic that "doesn't carry fine-grain flow labels" will still get sent through the load balancing mechanics, and packets with the same flow label will still get forwarded the same way. This is probably fine if a few related TCP connections are labelled with the same flow label, or something like that. It would be very bad, though, if the flow label were used, for example, to tag packets that contain a TCP SYN, or packets that contain IP options, or all HTTP packets, or packets that want a certain class of services, etc. My largest problem with this draft is that I think it is needlessly complex... What is wrong with specifying a simple default flow label mechanism, and requiring an API switch to override the values for each flow? 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 Sep 12 06:40:22 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8CDeMwf005554; Thu, 12 Sep 2002 06:40:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8CDeLlF005553; Thu, 12 Sep 2002 06:40:21 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8CDeGwf005546 for ; Thu, 12 Sep 2002 06:40:16 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8CDeKEV009257 for ; Thu, 12 Sep 2002 06:40:20 -0700 (PDT) Received: from fep04-mail.bloor.is.net.cable.rogers.com (fep04-mail.bloor.is.net.cable.rogers.com [66.185.86.74]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA11533 for ; Thu, 12 Sep 2002 07:40:14 -0600 (MDT) Received: from [192.168.1.100] ([24.42.214.149]) by fep04-mail.bloor.is.net.cable.rogers.com (InterMail vM.5.01.05.06 201-253-122-126-106-20020509) with ESMTP id <20020912134007.QYLE389684.fep04-mail.bloor.is.net.cable.rogers.com@[192.168.1.100]>; Thu, 12 Sep 2002 09:40:07 -0400 Mime-Version: 1.0 X-Sender: kgk@mailbox.ott.igs.net Message-Id: In-Reply-To: <5.1.0.14.2.20020912085147.0293e470@mail.windriver.com> References: <009CA59D1752DD448E07F8EB2F911757198158@esebe004.ntc.nokia.com> <5.1.0.14.2.20020911093503.0316bec0@mail.windriver.com> <5.1.0.14.2.20020912085147.0293e470@mail.windriver.com> Date: Thu, 12 Sep 2002 09:44:12 -0400 To: Margaret Wasserman , Brian E Carpenter From: Keith Knightson Subject: Re: Flow label draft issues & new text Cc: jarno.rajahalme@nokia.com, Erik.Nordmark@Sun.COM, kre@munnari.OZ.AU, narten@us.ibm.com, ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Authentication-Info: Submitted using SMTP AUTH LOGIN at fep04-mail.bloor.is.net.cable.rogers.com from [24.42.214.149] using ID at Thu, 12 Sep 2002 09:40:06 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk All, What happened to the proposal to partition the label space to clearly and formally delineate the different possible uses? Surely this would elminate any possible ambiguous and/or conflicting use. Regards Keith Knightson -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 12 08:21:56 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8CFLtwf005705; Thu, 12 Sep 2002 08:21:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8CFLtBB005704; Thu, 12 Sep 2002 08:21:55 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8CFLlwf005697 for ; Thu, 12 Sep 2002 08:21:47 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8CFLrPG010736 for ; Thu, 12 Sep 2002 08:21:53 -0700 (PDT) Received: from mail-gw2.hursley.ibm.com (mail-gw2.hursley.ibm.com [194.196.110.19]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA04621 for ; Thu, 12 Sep 2002 08:21:47 -0700 (PDT) Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw2.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.10) id 17pVms-0006h7-00; Thu, 12 Sep 2002 16:21:46 +0100 Received: from [9.20.45.103] (helo=sp15en17.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.10) id 17pVmr-0006h2-00; Thu, 12 Sep 2002 16:21:45 +0100 Received: from hursley.ibm.com (dhcp23-199.zurich.ibm.com [9.4.23.199]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id QAA33930; Thu, 12 Sep 2002 16:21:44 +0100 Message-ID: <3D80B119.F6E2FE58@hursley.ibm.com> Date: Thu, 12 Sep 2002 17:22:01 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Keith Knightson CC: Margaret Wasserman , jarno.rajahalme@nokia.com, Erik.Nordmark@Sun.COM, kre@munnari.OZ.AU, narten@us.ibm.com, ipng@sunroof.eng.sun.com Subject: Re: Flow label draft issues & new text References: <009CA59D1752DD448E07F8EB2F911757198158@esebe004.ntc.nokia.com> <5.1.0.14.2.20020911093503.0316bec0@mail.windriver.com> <5.1.0.14.2.20020912085147.0293e470@mail.windriver.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith Knightson wrote: > > All, > > What happened to the proposal to partition the label space to clearly > and formally delineate the different possible uses? > > Surely this would elminate any possible ambiguous and/or conflicting use. There was no consensus to go that way. So we looked for a more general 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 Sep 12 08:39:35 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8CFdZwf005769; Thu, 12 Sep 2002 08:39:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8CFdYkr005768; Thu, 12 Sep 2002 08:39:34 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8CFdRwf005761 for ; Thu, 12 Sep 2002 08:39:27 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8CFdWPG017452 for ; Thu, 12 Sep 2002 08:39:32 -0700 (PDT) Received: from mail-gw2.hursley.ibm.com (mail-gw2.hursley.ibm.com [194.196.110.19]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA03247 for ; Thu, 12 Sep 2002 08:39:27 -0700 (PDT) Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw2.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.10) id 17pVxo-00072W-00; Thu, 12 Sep 2002 16:33:04 +0100 Received: from [9.20.45.103] (helo=sp15en17.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.10) id 17pVxo-00072R-00; Thu, 12 Sep 2002 16:33:04 +0100 Received: from hursley.ibm.com (dhcp23-199.zurich.ibm.com [9.4.23.199]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id QAA32816; Thu, 12 Sep 2002 16:33:03 +0100 Message-ID: <3D80B3C0.B6B6EB9C@hursley.ibm.com> Date: Thu, 12 Sep 2002 17:33:20 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Margaret Wasserman CC: jarno.rajahalme@nokia.com, Erik.Nordmark@Sun.COM, kre@munnari.OZ.AU, narten@us.ibm.com, ipng@sunroof.eng.sun.com Subject: Re: Flow label draft issues & new text References: <009CA59D1752DD448E07F8EB2F911757198158@esebe004.ntc.nokia.com> <5.1.0.14.2.20020911093503.0316bec0@mail.windriver.com> <5.1.0.14.2.20020912085147.0293e470@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: > > > > >Jarno answered this one I think, but my point is that *they don't need to > >know*. They just behave the same way in all cases, and the traffic that > >doesn't carry fine-grain flow labels will just not get load balanced. > > The problem is that the traffic that "doesn't carry fine-grain flow labels" > will still get sent through the load balancing mechanics, and packets with > the same flow label will still get forwarded the same way. > > This is probably fine if a few related TCP connections are labelled with > the same flow label, or something like that. > > It would be very bad, though, if the flow label were used, for example, > to tag packets that contain a TCP SYN, or packets that contain IP options, Agreed. That doesn't meet anyone's definition of a flow, I think. > or all HTTP packets, or packets that want a certain class of services, etc. Why on earth is that bad? It seems perfectly fine to me. That is exactly the kind of scenario I am interested in. > My largest problem with this draft is that I think it is needlessly > complex... What is wrong with specifying a simple default flow label > mechanism, and requiring an API switch to override the values for > each flow? Because we don't agree on what the default should be (apart from label=0). And a per-flow override is not a general solution; the scenarios I have in mind would certainly not be satisfied by that, because they are not microflow based 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 Sep 12 09:24:14 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8CGODwf005864; Thu, 12 Sep 2002 09:24:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8CGODK1005863; Thu, 12 Sep 2002 09:24:13 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8CGO7wf005856 for ; Thu, 12 Sep 2002 09:24:07 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8CGODEV010283 for ; Thu, 12 Sep 2002 09:24:13 -0700 (PDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.54]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA00825; Thu, 12 Sep 2002 10:24:07 -0600 (MDT) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g8CGK6W4006714; Thu, 12 Sep 2002 09:20:07 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ACP01908; Thu, 12 Sep 2002 09:15:38 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA23535; Thu, 12 Sep 2002 09:20:05 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15744.48821.269755.914681@thomasm-u1.cisco.com> Date: Thu, 12 Sep 2002 09:20:05 -0700 (PDT) To: Margaret Wasserman Cc: Brian E Carpenter , jarno.rajahalme@nokia.com, Erik.Nordmark@Sun.COM, kre@munnari.OZ.AU, narten@us.ibm.com, ipng@sunroof.eng.sun.com Subject: Re: Flow label draft issues & new text In-Reply-To: <5.1.0.14.2.20020912085147.0293e470@mail.windriver.com> References: <009CA59D1752DD448E07F8EB2F911757198158@esebe004.ntc.nokia.com> <5.1.0.14.2.20020911093503.0316bec0@mail.windriver.com> <5.1.0.14.2.20020912085147.0293e470@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: > > > > >Jarno answered this one I think, but my point is that *they don't need to > >know*. They just behave the same way in all cases, and the traffic that > >doesn't carry fine-grain flow labels will just not get load balanced. > > The problem is that the traffic that "doesn't carry fine-grain flow labels" > will still get sent through the load balancing mechanics, and packets with > the same flow label will still get forwarded the same way. Margaret, Maybe I'm in left field here, but I thought that a transmitter who didn't mark packets' flow label was supposed to set it to zero. In that case, the router could conceivably resort to classifying packets the old fashioned way -- eg transport headers. > It would be very bad, though, if the flow label were used, for example, > to tag packets that contain a TCP SYN, or packets that contain IP options, > or all HTTP packets, or packets that want a certain class of services, etc. Er, why would this be bad? Are you thinking of the possibility of a host gaming a router's fair queuing by changing the flow label on packet by packet basis? 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 Sep 12 09:38:58 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8CGcwwf005930; Thu, 12 Sep 2002 09:38:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8CGcwf0005929; Thu, 12 Sep 2002 09:38:58 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8CGcqwf005922 for ; Thu, 12 Sep 2002 09:38:53 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8CGcwPG011470 for ; Thu, 12 Sep 2002 09:38:58 -0700 (PDT) Received: from cichlid.adsl.duke.edu (cichlid.adsl.duke.edu [152.16.64.203]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA19208 for ; Thu, 12 Sep 2002 10:38:52 -0600 (MDT) Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.11.6) with ESMTP id g8CGaS302919 for ; Thu, 12 Sep 2002 12:36:28 -0400 Message-Id: <200209121636.g8CGaS302919@cichlid.adsl.duke.edu> To: ipng@sunroof.eng.sun.com Subject: IESG comments on draft-ietf-ipngwg-addr-arch-v3-09.txt Date: Thu, 12 Sep 2002 12:36:28 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Good news. The IESG discussion of this document raised no major issues. One point that was discussed, however, was related to whether :: means "1 or more" occurances of zero vs. "2 or more", when used in an IPv6 literal address. The document currently says: > 2. Due to some methods of allocating certain styles of IPv6 > addresses, it will be common for addresses to contain long strings > of zero bits. In order to make writing addresses containing zero > bits easier a special syntax is available to compress the zeros. > The use of "::" indicates multiple groups of 16 bits of zeros. > The "::" can only appear once in an address. The "::" can also be > used to compress the leading and/or trailing zeros in an address. It turns out that an unscientific survey (one AD who got bitten once and recalled not understanding what was wrong with the address being typed in and another that then checked their implementation) at least two implementation happen to implement this differently. I.e., on one parser an address with :: denoting one occurance of zeros was accepted, on the other it was rejected. It would be good for the WG to clarify what meaning should be implemented, and then clarify the document. Once that is done, I expect the IESG to approve the document. Some other nits to fold in: > Minor nit. The first reference to EUI-64 should contain a reference. > this document does not say anywhere that it obsoletes > RFC 2373 - nor does the protocol action 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 Thu Sep 12 10:04:11 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8CH4Bwf006025; Thu, 12 Sep 2002 10:04:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8CH4Asl006024; Thu, 12 Sep 2002 10:04:10 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8CH44wf006017 for ; Thu, 12 Sep 2002 10:04:04 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8CH4APG023444 for ; Thu, 12 Sep 2002 10:04:11 -0700 (PDT) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA05149 for ; Thu, 12 Sep 2002 11:04:05 -0600 (MDT) Received: from kenawang.windriver.com ([147.11.233.11]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id KAA25894; Thu, 12 Sep 2002 10:02:39 -0700 (PDT) Message-Id: <5.1.0.14.2.20020912124354.02949660@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 12 Sep 2002 13:02:40 -0400 To: Michael Thomas From: Margaret Wasserman Subject: Re: Flow label draft issues & new text Cc: Brian E Carpenter , jarno.rajahalme@nokia.com, Erik.Nordmark@Sun.COM, kre@munnari.OZ.AU, narten@us.ibm.com, ipng@sunroof.eng.sun.com In-Reply-To: <15744.48821.269755.914681@thomasm-u1.cisco.com> References: <5.1.0.14.2.20020912085147.0293e470@mail.windriver.com> <009CA59D1752DD448E07F8EB2F911757198158@esebe004.ntc.nokia.com> <5.1.0.14.2.20020911093503.0316bec0@mail.windriver.com> <5.1.0.14.2.20020912085147.0293e470@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >Maybe I'm in left field here, but I thought that a >transmitter who didn't mark packets' flow label >was supposed to set it to zero. In that case, the >router could conceivably resort to classifying packets >the old fashioned way -- eg transport headers. The problem is that the current specification allows information other than a flow label, such as a packet classifier to be placed in the flow label field. So, a router cannot know that a non-zero value labels a flow (i.e. one direction of a TCP connection). > > It would be very bad, though, if the flow label were used, for example, > > to tag packets that contain a TCP SYN, or packets that contain IP options, > > or all HTTP packets, or packets that want a certain class of services, > etc. > >Er, why would this be bad? There are a couple of ways in which you would like to be able to use the flow label field to simplify load balancing. One is a router with support for multi-path routing. There is more than one path out of this box that will reach the same destination, perhaps with some sort of weighting value to indicate what portion of the traffic should be sent over each path. Today, these routers need to do packet classification on the IP addresses and the upper-layer port numbers if they want to avoid sending data from the same connection over different paths, which can result in packet reordering, etc. If the flow label actually labeled a flow, these routers could use the IP addresses and the flow label to keep packets from the same flow together, instead of having to parse the variable-length IP headers to find the upper-layer port numbers. Another application is a load-spreading router that spreads incoming TCP connections across a group of servers. This box sets up state for each incoming connection, and needs to ensure that all packets for the same connection are sent to the same server -- otherwise the connection will be reset. It would be useful if these boxes could set-up state based on the IP address and the flow label, instead of having to parse headers down to the TCP header to find the port numbers. Both of these mechanisms rely on the flow label labeling one direction of an upper-layer connection (the definition I usually associate with the word "flow"). If some nodes set their flow label to zero (indicating that they don't participate in flow labeling), these mechanisms will still work. The lookup for those packets will be less efficient, but it would still work. What doesn't work is if there may be non-zero values in the flow label that actually don't label flows. How is a load-balancing or load-spreading router supposed to know that this isn't a flow label? I gave two examples which Brian Carpenter said he specifically had in mind for possible uses of the flow label: - All HTTP packets get the same flow label. How would this work with a load spreader that is trying to spread connections between a group of web servers? - The flow label contains a packet classifier. This *might* be okay, if values aren't reused too often, and if a single connection always uses the same value. But, Brian specifically stated that he wants finer-grained control over flow label values than a per-connection value. How would that work with load-spreaders? If the WG really wants to define the flow label so that it can be used for signalling-based mechanisms like RSVP, NSIS and diffserv, with the clear understanding that this makes the value _USELESS_ for the types of applications I've described above, that is fine with me. But, it isn't true that the defined mechanism lets us do both. 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 Sep 12 10:43:15 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8CHhFwf006158; Thu, 12 Sep 2002 10:43:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8CHhEn2006157; Thu, 12 Sep 2002 10:43:14 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8CHh8wf006150 for ; Thu, 12 Sep 2002 10:43:08 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8CHhDEV014851 for ; Thu, 12 Sep 2002 10:43:13 -0700 (PDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.54]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA24861 for ; Thu, 12 Sep 2002 11:43:03 -0600 (MDT) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g8CHciW4027365; Thu, 12 Sep 2002 10:38:44 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ACP04430; Thu, 12 Sep 2002 10:34:17 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA23551; Thu, 12 Sep 2002 10:38:43 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15744.53539.537550.134748@thomasm-u1.cisco.com> Date: Thu, 12 Sep 2002 10:38:43 -0700 (PDT) To: Margaret Wasserman Cc: Michael Thomas , Brian E Carpenter , jarno.rajahalme@nokia.com, Erik.Nordmark@Sun.COM, kre@munnari.OZ.AU, narten@us.ibm.com, ipng@sunroof.eng.sun.com Subject: Re: Flow label draft issues & new text In-Reply-To: <5.1.0.14.2.20020912124354.02949660@mail.windriver.com> References: <5.1.0.14.2.20020912085147.0293e470@mail.windriver.com> <009CA59D1752DD448E07F8EB2F911757198158@esebe004.ntc.nokia.com> <5.1.0.14.2.20020911093503.0316bec0@mail.windriver.com> <5.1.0.14.2.20020912124354.02949660@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: > > > > >Maybe I'm in left field here, but I thought that a > >transmitter who didn't mark packets' flow label > >was supposed to set it to zero. In that case, the > >router could conceivably resort to classifying packets > >the old fashioned way -- eg transport headers. > > The problem is that the current specification allows information other > than a flow label, such as a packet classifier to be placed in the > flow label field. So, a router cannot know that a non-zero value labels > a flow (i.e. one direction of a TCP connection). I guess I don't understand why that's a bad thing. Routers currently classify flows with transport headers, etc, but that's because it's the only thing they _can_ classify with. The flow label pushes classification back to the host which, IMO, is where it really belongs since it's the only that that _really_ knows what constitutes a "flow". > > > It would be very bad, though, if the flow label were used, for example, > > > to tag packets that contain a TCP SYN, or packets that contain IP options, > > > or all HTTP packets, or packets that want a certain class of services, > > etc. > > > >Er, why would this be bad? [much elided] > What doesn't work is if there may be non-zero values in the flow label > that actually don't label flows. How is a load-balancing or load-spreading > router supposed to know that this isn't a flow label? Er, well, it _doesn't_. I guess I just don't attach any special meaning to the word "flow"; that is, a flow is whatever the host says is a flow. If it's bizarre, then well, why should the router care? Again, other than maybe gaming fair queuing algorithms[*], why do routers actually care about what constitutes the sematics of the flow? It's really in the host's best interest to be network friendly, right? To give routers information which increases the probability of forwarding its packets in the manner it hopes for, right? > I gave two examples which Brian Carpenter said he specifically had in > mind for possible uses of the flow label: > > - All HTTP packets get the same flow label. > > How would this work with a load spreader that is > trying to spread connections between a group > of web servers? Well assumedly the server farm wouldn't all have the same IP address, so they'd be different flows. > - The flow label contains a packet classifier. Er, but the flow label *is* an element of a packet classifier, or rather perhaps a replacement for the current method of classifying packets. I thought as far as routers are concerned, flow label were opaque and that no internal semantics were visible. > But, Brian specifically stated that he wants finer-grained control over > flow label values than a per-connection value. How would that work with > load-spreaders? This seems to me to be a self-healing problem: if it screws up load balancers by using strange definitions of flow, hosts are probably what will notice via reduced throughput and... stop doing that ("Doc it hurts when I hit myself in the head..."). Though I must say that I still don't see that it would hurt them. > If the WG really wants to define the flow label so that it can be used > for signalling-based mechanisms like RSVP, NSIS and diffserv, with the > clear understanding that this makes the value _USELESS_ for the types > of applications I've described above, that is fine with me. I'm still completely lost. How does it make it useless? Mike [*] this could conceivably be mitigated by first classifying by IP address and then draw down each different flow from its own token bucket, thus a host would only be screwing itself. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 12 12:04:43 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8CJ4hwf006776; Thu, 12 Sep 2002 12:04:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8CJ4hdE006775; Thu, 12 Sep 2002 12:04:43 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8CJ4bwf006768 for ; Thu, 12 Sep 2002 12:04:37 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8CJ4gEV024623 for ; Thu, 12 Sep 2002 12:04:42 -0700 (PDT) Received: from tndh.net (evrtwa1-ar8-4-65-028-011.evrtwa1.dsl-verizon.net [4.65.28.11]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA21586 for ; Thu, 12 Sep 2002 12:04:37 -0700 (PDT) Received: from eagleswings (127.0.0.1) by localhost (127.0.0.1) with [XMail 1.3 (Win32/Ix86) ESMTP Server] id for from ; Thu, 12 Sep 2002 12:04:35 -0700 Reply-To: From: "Tony Hain" To: "'Michael Thomas'" , "'Margaret Wasserman'" Cc: "'Brian E Carpenter'" , , , , , Subject: RE: Flow label draft issues & new text Date: Thu, 12 Sep 2002 12:03:45 -0700 Message-ID: <01b901c25a8f$1fcce4e0$011aa8c0@eagleswings> 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, Build 10.0.3416 In-Reply-To: <15744.53539.537550.134748@thomasm-u1.cisco.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Michael Thomas wrote: > ... snip > > What doesn't work is if there may be non-zero values in > the flow label > that actually don't label flows. How is a > load-balancing or load-spreading > router supposed to know > that this isn't a flow label? > > Er, well, it _doesn't_. I guess I just don't > attach any special meaning to the word "flow"; > that is, a flow is whatever the host says is a > flow. If it's bizarre, then well, why should > the router care? Again, other than maybe gaming > fair queuing algorithms[*], why do routers > actually care about what constitutes the > sematics of the flow? It's really in the host's > best interest to be network friendly, right? To > give routers information which increases the > probability of forwarding its packets in the > manner it hopes for, right? > > ... snip > Er, but the flow label *is* an element of a > packet classifier, or rather perhaps a > replacement for the current method of classifying > packets. I thought as far as routers are > concerned, flow label were opaque and that no > internal semantics were visible. > Mike is right, as far as middle-boxes are concerned the FL is opaque unless they have been given specific state to believe otherwise. There is no reason a load-spreader would have a problem with frequent reuse, or even all nodes deciding to use the same value for HTTP as long as it is basing its decisions on the Src/Dst/FL rather than just the FL. I do have comments on the text. I would like to see the following changed from: 4. Flow Labeling Requirements (4) The source SHOULD assign each new transport connection (e.g. TCP, SCTP) to a new flow. to: (4) The source SHOULD assign each unrelated transport connection (e.g. TCP, SCTP) to a new flow. This would keep it from conflicting with (3). 5. Flow State Establishment Requirements ... To enable co-existence of different methods in IPv6 nodes, the methods MUST meet the following basic requirements: ... (3) The IPv6 node facility keeping track of the Flow Label and the associated Source and Destination Addresses MUST be utilized when assigning Flow Label values to new flows (see section 4 above). That wording seems awkward, how about: (3) The IPv6 source node MUST provide a facility for keeping track of the Flow Label values associated with particular Source and Destination Addresses for use when assigning Flow Label to new flows (see section 4 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 Sep 12 13:28:24 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8CKSOwf007294; Thu, 12 Sep 2002 13:28:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8CKSO91007293; Thu, 12 Sep 2002 13:28:24 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8CKSIwf007286 for ; Thu, 12 Sep 2002 13:28:18 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8CKSOPG024837 for ; Thu, 12 Sep 2002 13:28:25 -0700 (PDT) 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 OAA16849 for ; Thu, 12 Sep 2002 14:28:18 -0600 (MDT) 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 g8CKSBR23165; Thu, 12 Sep 2002 22:28:11 +0200 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 WAA22506; Thu, 12 Sep 2002 22:28:12 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id g8CKSB6o085272; Thu, 12 Sep 2002 22:28:11 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200209122028.g8CKSB6o085272@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Thomas Narten cc: ipng@sunroof.eng.sun.com Subject: Re: IESG comments on draft-ietf-ipngwg-addr-arch-v3-09.txt In-reply-to: Your message of Thu, 12 Sep 2002 12:36:28 EDT. <200209121636.g8CGaS302919@cichlid.adsl.duke.edu> Date: Thu, 12 Sep 2002 22:28:11 +0200 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: One point that was discussed, however, was related to whether :: means "1 or more" occurances of zero vs. "2 or more", when used in an IPv6 literal address. => I always interpreted this as "one or more" (i.e., the standard "+"). I.e., on one parser an address with :: denoting one occurance of zeros was accepted, on the other it was rejected. => the first is right, the second is wrong and must be fixed. Thanks Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Sep 12 13:35:26 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8CKZQwf007379; Thu, 12 Sep 2002 13:35:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8CKZPG1007378; Thu, 12 Sep 2002 13:35:25 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8CKZJwf007371 for ; Thu, 12 Sep 2002 13:35:20 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8CKZQPG028298 for ; Thu, 12 Sep 2002 13:35:26 -0700 (PDT) Received: from ncsmtp03.southeast.rr.com (ncsmtp03.ogw.rr.com [24.93.67.84]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA27138 for ; Thu, 12 Sep 2002 14:35:19 -0600 (MDT) Received: from mail4.nc.rr.com (fe4 [24.93.67.51]) by ncsmtp03.southeast.rr.com (8.12.5/8.12.2) with ESMTP id g8CKYMoC026353; Thu, 12 Sep 2002 16:34:22 -0400 (EDT) Received: from nc.rr.com ([24.162.252.183]) by mail4.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Thu, 12 Sep 2002 16:34:23 -0400 Message-ID: <3D80F9AC.1FDD202B@nc.rr.com> Date: Thu, 12 Sep 2002 16:31:40 -0400 From: Brian Haberman X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Michael Thomas CC: Margaret Wasserman , Brian E Carpenter , jarno.rajahalme@nokia.com, Erik.Nordmark@Sun.COM, kre@munnari.oz.au, narten@us.ibm.com, ipng@sunroof.eng.sun.com Subject: Re: Flow label draft issues & new text References: <5.1.0.14.2.20020912085147.0293e470@mail.windriver.com> <009CA59D1752DD448E07F8EB2F911757198158@esebe004.ntc.nokia.com> <5.1.0.14.2.20020911093503.0316bec0@mail.windriver.com> <5.1.0.14.2.20020912124354.02949660@mail.windriver.com> <15744.53539.537550.134748@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: > > Margaret Wasserman writes: > > > > If the WG really wants to define the flow label so that it can be used > > for signalling-based mechanisms like RSVP, NSIS and diffserv, with the > > clear understanding that this makes the value _USELESS_ for the types > > of applications I've described above, that is fine with me. > > I'm still completely lost. How does it make it > useless? I must be lost as well. In my reading of the flow label spec, I see the capability to do load balancing quite easily. The host sending the data assigns unique flow labels however it wants (just like Erik had mentioned). The routers can then either forward based solely on the DA or it can hash the for load balancing. If you want to talk DiffServ, IntServ, or something of that flavor, the flow label would be signaled, the router would recognize it during packet classification and deal with it how it sees fit. So, my opinion is that the spec does what it set out to accomplish. 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 Sep 12 13:51:17 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8CKpGwf007450; Thu, 12 Sep 2002 13:51:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8CKpGru007449; Thu, 12 Sep 2002 13:51:16 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8CKpAwf007442 for ; Thu, 12 Sep 2002 13:51:10 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8CKpGPG006522 for ; Thu, 12 Sep 2002 13:51:17 -0700 (PDT) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA22655; Thu, 12 Sep 2002 13:51:11 -0700 (PDT) Received: from kenawang.windriver.com ([147.11.233.11]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id NAA13521; Thu, 12 Sep 2002 13:50:15 -0700 (PDT) Message-Id: <5.1.0.14.2.20020912164910.029dd7f0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 12 Sep 2002 16:51:29 -0400 To: Brian Haberman From: Margaret Wasserman Subject: Re: Flow label draft issues & new text Cc: Michael Thomas , Brian E Carpenter , jarno.rajahalme@nokia.com, Erik.Nordmark@Sun.COM, kre@munnari.oz.au, narten@us.ibm.com, ipng@sunroof.eng.sun.com In-Reply-To: <3D80F9AC.1FDD202B@nc.rr.com> References: <5.1.0.14.2.20020912085147.0293e470@mail.windriver.com> <009CA59D1752DD448E07F8EB2F911757198158@esebe004.ntc.nokia.com> <5.1.0.14.2.20020911093503.0316bec0@mail.windriver.com> <5.1.0.14.2.20020912124354.02949660@mail.windriver.com> <15744.53539.537550.134748@thomasm-u1.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >If >you want to talk DiffServ, IntServ, or something of that flavor, the >flow label would be signaled, the router would recognize it during >packet classification and deal with it how it sees fit. So, all of the routers would have to participate in signalling to know whether the flow label was used for DiffServ, IntServ, etc.? Or, it would just work to use the flow label for load balancing, even it it contained a DiffServ or IntServ value, instead of labeling a microflow? 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 Sep 12 14:09:21 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8CL9Kwf007700; Thu, 12 Sep 2002 14:09:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8CL9K28007699; Thu, 12 Sep 2002 14:09:20 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8CL9Ewf007689 for ; Thu, 12 Sep 2002 14:09:14 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8CL9IPG014465 for ; Thu, 12 Sep 2002 14:09:18 -0700 (PDT) Received: from ncsmtp02.southeast.rr.com (ncsmtp02.ogw.rr.com [24.93.67.83]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA15844; Thu, 12 Sep 2002 15:09:13 -0600 (MDT) Received: from mail4.nc.rr.com (fe4 [24.93.67.51]) by ncsmtp02.southeast.rr.com (8.12.5/8.12.2) with ESMTP id g8CL90CJ000130; Thu, 12 Sep 2002 17:09:00 -0400 (EDT) Received: from nc.rr.com ([24.162.252.183]) by mail4.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Thu, 12 Sep 2002 17:08:29 -0400 Message-ID: <3D8101AD.24DEE96@nc.rr.com> Date: Thu, 12 Sep 2002 17:05:49 -0400 From: Brian Haberman X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Margaret Wasserman CC: Michael Thomas , Brian E Carpenter , jarno.rajahalme@nokia.com, Erik.Nordmark@Sun.COM, kre@munnari.oz.au, narten@us.ibm.com, ipng@sunroof.eng.sun.com Subject: Re: Flow label draft issues & new text References: <5.1.0.14.2.20020912085147.0293e470@mail.windriver.com> <009CA59D1752DD448E07F8EB2F911757198158@esebe004.ntc.nokia.com> <5.1.0.14.2.20020911093503.0316bec0@mail.windriver.com> <5.1.0.14.2.20020912124354.02949660@mail.windriver.com> <15744.53539.537550.134748@thomasm-u1.cisco.com> <5.1.0.14.2.20020912164910.029dd7f0@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: > > >If > >you want to talk DiffServ, IntServ, or something of that flavor, the > >flow label would be signaled, the router would recognize it during > >packet classification and deal with it how it sees fit. > > So, all of the routers would have to participate in signalling to > know whether the flow label was used for DiffServ, IntServ, etc.? > > Or, it would just work to use the flow label for load balancing, > even it it contained a DiffServ or IntServ value, instead of > labeling a microflow? How DiffServ and IntServ work with the flow label is yet to be determined. All I am saying is that the current spec does not preclude any of the functions mentioned above. Isn't that the point of the draft? As Matt said, the host knows best what a flow is. Whether that flow gets signaled to routers for special handling or not is outside the scope of this doc. 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 Sep 12 14:47:00 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8CLkxwf007916; Thu, 12 Sep 2002 14:46:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8CLkxkA007915; Thu, 12 Sep 2002 14:46:59 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8CLkswf007908 for ; Thu, 12 Sep 2002 14:46:54 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8CLkxEV008843 for ; Thu, 12 Sep 2002 14:46:59 -0700 (PDT) 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 PAA05014 for ; Thu, 12 Sep 2002 15:46:53 -0600 (MDT) 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 OAA20919; Thu, 12 Sep 2002 14:46:52 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g8CLkoQ32008; Thu, 12 Sep 2002 14:46:50 -0700 X-mProtect: <200209122146> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (4.22.78.78, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdWKnzMm; Thu, 12 Sep 2002 14:46:49 PDT Message-Id: <4.3.2.7.2.20020912143753.028b5a00@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 12 Sep 2002 14:46:44 -0700 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: Re: IESG comments on draft-ietf-ipngwg-addr-arch-v3-09.txt Cc: Thomas Narten In-Reply-To: <200209121636.g8CGaS302919@cichlid.adsl.duke.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk To resolve this issue, I propose the following text for section 2.2 (changed line indicated by "|" ): 2. Due to some methods of allocating certain styles of IPv6 addresses, it will be common for addresses to contain long strings of zero bits. In order to make writing addresses containing zero bits easier a special syntax is available to compress the zeros. The use of "::" indicates one or more groups of 16 bits of zeros. | The "::" can only appear once in an address. The "::" can also be used to compress the leading and/or trailing zeros in an address. Unless there is an objection, I will submit a new draft tomorrow with this change (as well as the reference and obsoletes RFC2373 changes). Bob At 09:36 AM 9/12/2002, Thomas Narten wrote: >Good news. The IESG discussion of this document raised no major >issues. One point that was discussed, however, was related to whether >:: means "1 or more" occurances of zero vs. "2 or more", when used in >an IPv6 literal address. The document currently says: > > > 2. Due to some methods of allocating certain styles of IPv6 > > addresses, it will be common for addresses to contain long strings > > of zero bits. In order to make writing addresses containing zero > > bits easier a special syntax is available to compress the zeros. > > The use of "::" indicates multiple groups of 16 bits of zeros. > > The "::" can only appear once in an address. The "::" can also be > > used to compress the leading and/or trailing zeros in an address. > >It turns out that an unscientific survey (one AD who got bitten once >and recalled not understanding what was wrong with the address being >typed in and another that then checked their implementation) at least >two implementation happen to implement this differently. I.e., on one >parser an address with :: denoting one occurance of zeros was >accepted, on the other it was rejected. > >It would be good for the WG to clarify what meaning should be >implemented, and then clarify the document. Once that is done, I >expect the IESG to approve the document. > >Some other nits to fold in: > > > Minor nit. The first reference to EUI-64 should contain a reference. > > > this document does not say anywhere that it obsoletes > > RFC 2373 - nor does the protocol action > >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 Thu Sep 12 15:06:39 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8CM6dwf008052; Thu, 12 Sep 2002 15:06:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8CM6ck5008051; Thu, 12 Sep 2002 15:06:38 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8CM6Xwf008044 for ; Thu, 12 Sep 2002 15:06:33 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8CM6cEV017715 for ; Thu, 12 Sep 2002 15:06:38 -0700 (PDT) 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 QAA28789; Thu, 12 Sep 2002 16:06:32 -0600 (MDT) Received: from kenawang.windriver.com ([147.11.233.11]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id PAA10142; Thu, 12 Sep 2002 15:05:15 -0700 (PDT) Message-Id: <5.1.0.14.2.20020912175223.031cbc70@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 12 Sep 2002 18:05:13 -0400 To: Brian Haberman From: Margaret Wasserman Subject: Re: Flow label draft issues & new text Cc: Michael Thomas , Brian E Carpenter , jarno.rajahalme@nokia.com, Erik.Nordmark@Sun.COM, kre@munnari.oz.au, narten@us.ibm.com, ipng@sunroof.eng.sun.com In-Reply-To: <3D8101AD.24DEE96@nc.rr.com> References: <5.1.0.14.2.20020912085147.0293e470@mail.windriver.com> <009CA59D1752DD448E07F8EB2F911757198158@esebe004.ntc.nokia.com> <5.1.0.14.2.20020911093503.0316bec0@mail.windriver.com> <5.1.0.14.2.20020912124354.02949660@mail.windriver.com> <15744.53539.537550.134748@thomasm-u1.cisco.com> <5.1.0.14.2.20020912164910.029dd7f0@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I think that the problem is that we have different ideas about what the purpose of this document is. I, personally, would like to see a document that defines how hosts should set the flow label, in the absence of knowledge to the contrary. Something like: - Start with a random number - Label each microflow (i.e. one half of a TCP, UDP or SCTP communication) with a new flow number - Supply an API for flow label override on a per-microflow basis Based on that document, it would be safe for routers to assume that a non-zero flow-label labels a microflow. If other WGs want to define signalling mechanisms that run above IP, those mechanisms can use the aforementioned API to set the appropriate signalled values. But, anything that wants to do this would have to be consistent with the fact that some routers will assume that the src/dest/flow label triplet labels a microflow. This seems a lot simpler than the current doc, and would allow routers to make some immediate use of the flow label field to limit situations where they need to parse into the packet to find upper-layer ports (parse once, and cache the value based on src/dst/flow label). Granted, this might make it harder to use the flow label field for mechanisms that want to do things other than label microflows, but it we already have a traffic class field for things that want to label packets with traffic classes. Margaret At 05:05 PM 9/12/02, Brian Haberman wrote: >Margaret Wasserman wrote: > > > > >If > > >you want to talk DiffServ, IntServ, or something of that flavor, the > > >flow label would be signaled, the router would recognize it during > > >packet classification and deal with it how it sees fit. > > > > So, all of the routers would have to participate in signalling to > > know whether the flow label was used for DiffServ, IntServ, etc.? > > > > Or, it would just work to use the flow label for load balancing, > > even it it contained a DiffServ or IntServ value, instead of > > labeling a microflow? > >How DiffServ and IntServ work with the flow label is yet to be >determined. All I am saying is that the current spec does not >preclude any of the functions mentioned above. Isn't that the >point of the draft? > >As Matt said, the host knows best what a flow is. Whether that >flow gets signaled to routers for special handling or not is >outside the scope of this doc. > >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 Sep 12 16:04:58 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8CN4vwf008194; Thu, 12 Sep 2002 16:04:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8CN4vJI008193; Thu, 12 Sep 2002 16:04:57 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8CN4pwf008186 for ; Thu, 12 Sep 2002 16:04:52 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8CN4vPG006558 for ; Thu, 12 Sep 2002 16:04:57 -0700 (PDT) Received: from tndh.net (evrtwa1-ar8-4-65-028-011.evrtwa1.dsl-verizon.net [4.65.28.11]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA29857 for ; Thu, 12 Sep 2002 16:04:52 -0700 (PDT) Received: from eagleswings (127.0.0.1) by localhost (127.0.0.1) with [XMail 1.3 (Win32/Ix86) ESMTP Server] id for from ; Thu, 12 Sep 2002 16:04:46 -0700 Reply-To: From: "Tony Hain" To: "'Margaret Wasserman'" , "'Brian Haberman'" Cc: "'Michael Thomas'" , "'Brian E Carpenter'" , , , , , Subject: RE: Flow label draft issues & new text Date: Thu, 12 Sep 2002 16:03:41 -0700 Message-ID: <01e501c25ab0$a325e9b0$011aa8c0@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <5.1.0.14.2.20020912175223.031cbc70@mail.windriver.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g8CN4qwf008187 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret Wasserman wrote: > I think that the problem is that we have different ideas > about what the purpose of this document is. > > I, personally, would like to see a document that defines how > hosts should set the flow label, in the absence of knowledge > to the contrary. Something like: > > - Start with a random number > - Label each microflow (i.e. one half of a TCP, UDP or > SCTP communication) with a new flow number This is what it specifically can't do if the host is expecting multiple connections to be treated as a bundle! > - Supply an API for flow label override on a per-microflow > basis > > Based on that document, it would be safe for routers to > assume that a non-zero flow-label labels a microflow. > > If other WGs want to define signalling mechanisms that run > above IP, those mechanisms can use the aforementioned API to > set the appropriate signalled values. But, anything that > wants to do this would have to be consistent with the fact > that some routers will assume that the src/dest/flow label > triplet labels a microflow. > > This seems a lot simpler than the current doc, and would > allow routers to make some immediate use of the flow label > field to limit situations where they need to parse into the > packet to find upper-layer ports (parse once, and cache the > value based on src/dst/flow label). It can be argued that a router never *needs* to parse into the packet beyond the addresses. It can also be argued that if the FL is non-zero that the router has absolutely no business parsing into the packet, because the host has identified anything with this label as needing the same treatement by the router. As far as I can tell the document is about as simple as it can be, and trying to become more specific about how the FL gets used will only complicate it once all the possible uses are added. Tony > > Granted, this might make it harder to use the flow label > field for mechanisms that want to do things other than label > microflows, but it we already have a traffic class field for > things that want to label packets with traffic classes. > > Margaret > > At 05:05 PM 9/12/02, Brian Haberman wrote: > > > >Margaret Wasserman wrote: > > > > > > >If > > > >you want to talk DiffServ, IntServ, or something of that flavor, > > > >the flow label would be signaled, the router would recognize it > > > >during packet classification and deal with it how it sees fit. > > > > > > So, all of the routers would have to participate in signalling to > > > know whether the flow label was used for DiffServ, IntServ, etc.? > > > > > > Or, it would just work to use the flow label for load balancing, > > > even it it contained a DiffServ or IntServ value, instead of > > > labeling a microflow? > > > >How DiffServ and IntServ work with the flow label is yet to be > >determined. All I am saying is that the current spec does > not preclude > >any of the functions mentioned above. Isn't that the point of the > >draft? > > > >As Matt said, the host knows best what a flow is. Whether that flow > >gets signaled to routers for special handling or not is outside the > >scope of this doc. > > > >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 Sep 12 20:04:49 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8D34mwf008729; Thu, 12 Sep 2002 20:04:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8D34mxe008728; Thu, 12 Sep 2002 20:04:48 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8D34fwf008721 for ; Thu, 12 Sep 2002 20:04:41 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8D34kPG021757 for ; Thu, 12 Sep 2002 20:04:46 -0700 (PDT) Received: from hall.mail.mindspring.net (hall.mail.mindspring.net [207.69.200.60]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA11206 for ; Thu, 12 Sep 2002 20:04:41 -0700 (PDT) Received: from dialup-64.157.115.110.dial1.dallas1.level3.net ([64.157.115.110] helo=ix.netcom.com) by hall.mail.mindspring.net with esmtp (Exim 3.33 #1) id 17pgko-00032I-00; Thu, 12 Sep 2002 23:04:22 -0400 Message-ID: <3D81708A.556A9B23@ix.netcom.com> Date: Thu, 12 Sep 2002 21:58:51 -0700 From: Jeff Williams Organization: INEGroup Spokesman X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit) MIME-Version: 1.0 To: Joe Baptista CC: "DNSO, General Assembly" , ISI IPv6 list <6bone@ISI.EDU>, Internet Architecture Board , "ipng@sunroof.eng.sun.com" , vint Cerf , atlarge discuss list Subject: Re: [ga] Overcoming IPv6 Security Threat References: <5.1.0.14.0.20020912103632.00a1e580@wheresmymailserver.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Joe and all assembly members other interested parties, Thanks Joe for passing this interesting and very accurate article. It is good that also Jim FLemings IPv8 got a little well deserved attention as well. Kudos to Jim there! Indeed the security and privacy problems with IPv6 despite the discounting from some sectors including IPv6 champion, Vint Cerf, has finally come to a more accurate evaluation.. Joe Baptista wrote: > Thanks to everyone who helped out. > > cheers > joe baptista > > >http://www.circleid.com/articles/2533.asp > > > >Overcoming IPv6 Security Threat > > > >September 12, 2002 | By Joe Baptista > > > >Technology rags and industry pundits see IPv6 (Internet Protocol version > >6) as the future of networking, but Daniel Golding a participant of the > >North American Network Operators' Group (NANOG) thinks it's a "solution in > >search of a problem". Many others have argued IPv6 is a problem in itself > >and it is unlikely the protocol will gain wide acceptance in the short > >term. > > > >IPv6 does solve many of the problems with the current version of IPv4 > >(Internet Protocol version 4). Its purpose is to expand address space and > >fix the IPv4 address depletion problem, which many techies claim, was due > >to mismanagement. The industry's goal is to use the very large address > >allocation pool in IPv6 to expand the capabilities of the Internet to > >enable a variety of peer-to-peer and mobile applications including > >cellular phone technology and home networking. > > > >IPv6, a suite of protocols for the network layer, uses IPv4 gateways to > >interconnect IPv6 nodes and comes prepackaged with some popular operating > >systems. This includes almost all Unix flavors, some Windows versions and > >Mac OS. Some vendors offer upgrades to older operating systems. Trumpet > >Software International in Tasmania Australia manufactures a Trumpet > >Winsock version that upgrades old Windows 95/98 and NT systems to the > >current IPv6 standard. > > > >IPv6 has suffered bad press over privacy issues. Jim Fleming, the inventor > >of IPv8, a competing protocol, sees many hazards and privacy flaws in > >existing IPv6 implementations. IPv6 address space in some cases uses an ID > >(identifier) derived from your hardware or phone "that allows your packets > >to be traced back to your PC or cell-phone" said Fleming. Potential abuse > >to user privacy exists as a hardware ID wired into the IPv6 protocol can > >be used to determine the manufacturer, make and model number, and value of > >the hardware equipment being used. Fleming warns users to think twice > >before they buy themselves a used Laptop computer and inherit all the > >prior surfing history of the previous user! > > > >IPv6 uses 128 bits to provide addressing, routing, and identification > >information on a computer interface or network card. The 128 bits are > >divided into the left 64 and the right 64. Some IPv6 systems use the right > >64 bits to store an IEEE defined global identifier (EUI64). This > >identifier is composed of company id value assigned to a manufacturer by > >the IEEE Registration Authority. The 64-bit identifier is a concatenation > >of the 24-bit company identification value and a 40-bit extension > >identifier assigned by the organization with that company identification > >assignment. The 48-bit MAC address of your network interface card may also > >be used to make up the EUI64. > > > >In the early stages of IPv6 development, Bill Frezza a General Partner > >with the venture capital firm, Adams Capital Management warned software > >developers that if privacy issues are not properly addressed, the > >migration to IPv6 "will blow up in their face"! Leah Gallegos agrees that > >while "expanding the address space is necessary the use of the address for > >ID and tracking is horrific". Gallegos the operator of the top-level > >domain .BIZ and a Director of the Top Level Domain Association cautions > >network administrators that they should refuse to implement IPv6 unless > >these issues are properly addressed. > > > >Privacy concerns prompted the creation of new standards, which provide > >privacy extensions to IPv6 devices. Thomas Narten and Track Draves of > >Microsoft Research published a procedure to ensure privacy of IPv6 users. > >Narten, IBM's technical lead on IPv6 and an Area Director for the Internet > >Engineering Task Force (IETF), agrees "IPv6 address can, in some cases, > >include an identifier derived from a hardware address". But Narten points > >out that a hardware address is not required. "In cases where using a > >permanent identifier is a problem", said Narten "RFC 3041 addresses should > >be used". > > > >RFC 3041 titled "Privacy Extensions for Stateless Address > >Autoconfiguration in IPv6" was published this past January 2001 by the > >IETF. It is an algorithm developed jointly by Narten and Draves which > >generates randomized interface identifiers and temporary addressees during > >a user session. This would eliminate the concerns privacy advocates have > >with IPv6. > > > >Unfortunately RFC 3041 is not widely implemented. But Narten expects major > >vendors to incorporate his privacy standard and offered that Microsoft > >implemented privacy extensions "and apparently intends to make it part of > >their standard stuff". Narten also assisted in the drafting of > >recommendations for some second and third generation cellular phones > >recently approved for publication by the Internet Engineering Steering > >Group. That document recommends that RFC 3041 be implemented as part of > >cellular phone technology but he did not know what direction cell phones > >manufacturers were taking. "I suspect that client vendors will generally > >implement it because of the potential bad PR if they don't" said Narten. > > > >Another obstacle raised by NANOG operators is that there is currently no > >commercial demand for IPv6 at this time. Dave Israel, a Data Network > >Engineer and regular participant on NANOG lists, sees no immediate demand > >for IPv6 services. "The only people who ask me about IPv6", said Israel > >"are people who have heard something about it from some tech-magazine and > >want the newest thing". Israel says he sees no commercial demand for a v6 > >backbone. > > > >Daniel Golding, another NANOG participant agrees, "v6 deployment is being > >encouraged by some countries, and the spread of 3G (cellular technology) > >is helping things along, but we have yet to see really widespread v6 > >deployments anywhere". Golding sees major backbone networks deploying IPv6 > >when it makes economic sense for them to do so. "Right now", said Golding > >"there is no demand and no revenue upside. I don't expect this to change > >in the near future". > > > >Most on NANOG agree the roadblock seems to be a lack of ISPs that offer > >IPv6 services. Stephen Sprunk, a Network Design Consultant with Cisco's > >Advanced Services group sees the "greater adoption of always-on broadband > >access will be the necessary push" to get IPv6 off the ground. "Enterprise > >networks will not be the driver for ISPs to go to IPv6" said Sprunk and > >"NAT is too entrenched". Network Address Translation (NAT) is a method of > >connecting multiple computers to the Internet (or any other IP network) > >using one IPv4 address. > > > >Vint Cerf senior vice president of architecture & technology at WorldCom > >has been using IPv6 for about four years. IPv6 has been a key element for > >some of WorldCom's Government customers. Cerf thinks IPv6 supporters have > >a lot of work ahead to achieve successful deployment of the protocol. He > >expects "that over the next several years we will see a lot of consumer > >devices set up to work with IPv6" and "cell phones are likely candidates, > >as are radio-enabled PDAs". > > > >-EOF > > The dot.GOD Registry, Limited > http://www.dot-god.com/ Regards, -- Jeffrey A. Williams Spokesman for INEGroup - (Over 127k members/stakeholders strong!) CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng. Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 214-244-4827 or 972-244-3801 Address: 5 East Kirkwood Blvd. Grapevine Texas 75208 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 12 21:49:36 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8D4nZwf009040; Thu, 12 Sep 2002 21:49:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8D4nZ4h009039; Thu, 12 Sep 2002 21:49:35 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8D4nUwf009032 for ; Thu, 12 Sep 2002 21:49:30 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8D4nZEV025559 for ; Thu, 12 Sep 2002 21:49:35 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA06875 for ; Thu, 12 Sep 2002 22:49:29 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g8D4msA22911; Fri, 13 Sep 2002 07:48:54 +0300 Date: Fri, 13 Sep 2002 07:48:53 +0300 (EEST) From: Pekka Savola To: Jeff Williams cc: Joe Baptista , "DNSO, General Assembly" , ISI IPv6 list <6bone@ISI.EDU>, Internet Architecture Board , "ipng@sunroof.eng.sun.com" , vint Cerf , atlarge discuss list Subject: Re: [ga] Overcoming IPv6 Security Threat In-Reply-To: <3D81708A.556A9B23@ix.netcom.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, 12 Sep 2002, Jeff Williams wrote: > Joe and all assembly members other interested parties, > > Thanks Joe for passing this interesting and very accurate article. Hmm.. > It is good that also Jim FLemings IPv8 got a little well deserved > attention as well. Kudos to Jim there! You must be kidding! -- 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 Sep 12 22:24:18 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8D5OHwf009193; Thu, 12 Sep 2002 22:24:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8D5OHXf009192; Thu, 12 Sep 2002 22:24:17 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8D5OCwf009185 for ; Thu, 12 Sep 2002 22:24:12 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8D5OHEV003939 for ; Thu, 12 Sep 2002 22:24:17 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA01225 for ; Thu, 12 Sep 2002 23:24:11 -0600 (MDT) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 0F3EB6A901; Fri, 13 Sep 2002 08:23:54 +0300 (EEST) Message-ID: <3D8177B1.5070800@kolumbus.fi> Date: Fri, 13 Sep 2002 08:29:21 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020516 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeff Williams Cc: Joe Baptista , "ipng@sunroof.eng.sun.com" Subject: Re: [ga] Overcoming IPv6 Security Threat References: <5.1.0.14.0.20020912103632.00a1e580@wheresmymailserver.com> <3D81708A.556A9B23@ix.netcom.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jeff Williams wrote: > Thanks Joe for passing this interesting and very accurate article. Reading on... >>>IPv6 has suffered bad press over privacy issues. Jim Fleming, the inventor >>>of IPv8, a competing protocol, sees many hazards and privacy flaws in >>>existing IPv6 implementations. IPv6 address space in some cases uses an ID >>>(identifier) derived from your hardware or phone "that allows your packets >>>to be traced back to your PC or cell-phone" said Fleming. Potential abuse >>>to user privacy exists as a hardware ID wired into the IPv6 protocol can >>>be used to determine the manufacturer, make and model number, and value of >>>the hardware equipment being used. Generally speaking, cell phones don't have EUI64 identifiers and the network allocates a (typically random) interface identifier part that the phones can use when they generate their addresses. Furthermore, the phones get a new prefix part every time they reconnect to the network, e.g., after being out of coverage for a while. And on top of this, you can also use RFC 3041... I'd say we are pretty well covered for privacy. When a laptop-phone configuration is used, the laptop's EUI64 may become visible more easily. The changing network prefix and RFC 3041 can help there. Jari -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Sep 12 23:58:13 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8D6wDwf009357; Thu, 12 Sep 2002 23:58:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8D6wDIh009356; Thu, 12 Sep 2002 23:58:13 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8D6w5wf009349 for ; Thu, 12 Sep 2002 23:58:05 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8D6w8PG017531 for ; Thu, 12 Sep 2002 23:58:08 -0700 (PDT) Received: from mail-gw2.hursley.ibm.com (mail-gw2.hursley.ibm.com [194.196.110.19]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA08804 for ; Fri, 13 Sep 2002 00:58:02 -0600 (MDT) Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw2.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.10) id 17pkOv-0007GS-00; Fri, 13 Sep 2002 07:58:01 +0100 Received: from [9.20.45.103] (helo=sp15en17.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.10) id 17pkOv-0007GN-00; Fri, 13 Sep 2002 07:58:01 +0100 Received: from hursley.ibm.com (dhcp23-199.zurich.ibm.com [9.4.23.199]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id HAA40824; Fri, 13 Sep 2002 07:57:59 +0100 Message-ID: <3D818C87.1B025185@hursley.ibm.com> Date: Fri, 13 Sep 2002 08:58:15 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Margaret Wasserman CC: Brian Haberman , Michael Thomas , jarno.rajahalme@nokia.com, Erik.Nordmark@Sun.COM, kre@munnari.oz.au, narten@us.ibm.com, ipng@sunroof.eng.sun.com Subject: Re: Flow label draft issues & new text References: <5.1.0.14.2.20020912085147.0293e470@mail.windriver.com> <009CA59D1752DD448E07F8EB2F911757198158@esebe004.ntc.nokia.com> <5.1.0.14.2.20020911093503.0316bec0@mail.windriver.com> <5.1.0.14.2.20020912124354.02949660@mail.windriver.com> <15744.53539.537550.134748@thomasm-u1.cisco.com> <5.1.0.14.2.20020912164910.029dd7f0@mail.windriver.com> <5.1.0.14.2.20020912175223.031cbc70@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 think that the problem is that we have different ideas about > what the purpose of this document is. > > I, personally, would like to see a document that defines how hosts > should set the flow label, in the absence of knowledge to the > contrary. That is not the intended purpose of the current draft, which is to set boundary conditions that allow hosts, routers, and network processors to stop treating the label as an MBZ field. Once we have set these boundary conditions, we can then work out specific scenarios. It is not a given that the default scenario is load balancing; I doubt if there is a default scenario, apart from label=0. Michael Thomas, Tony Hain and Brian Haberman have responded to your other comments much as I would. But basically, a flow is whatever the source host decides is a flow. Brian > ...Something like: > > - Start with a random number > - Label each microflow (i.e. one half of a TCP, UDP or > SCTP communication) with a new flow number > - Supply an API for flow label override on a per-microflow > basis > > Based on that document, it would be safe for routers to assume > that a non-zero flow-label labels a microflow. > > If other WGs want to define signalling mechanisms that run > above IP, those mechanisms can use the aforementioned API to set > the appropriate signalled values. But, anything that wants to do > this would have to be consistent with the fact that some routers > will assume that the src/dest/flow label triplet labels a microflow. > > This seems a lot simpler than the current doc, and would allow > routers to make some immediate use of the flow label field to > limit situations where they need to parse into the packet to > find upper-layer ports (parse once, and cache the value based > on src/dst/flow label). > > Granted, this might make it harder to use the flow label field for > mechanisms that want to do things other than label microflows, but > it we already have a traffic class field for things that want to > label packets with traffic classes. > > Margaret > > At 05:05 PM 9/12/02, Brian Haberman wrote: > > >Margaret Wasserman wrote: > > > > > > >If > > > >you want to talk DiffServ, IntServ, or something of that flavor, the > > > >flow label would be signaled, the router would recognize it during > > > >packet classification and deal with it how it sees fit. > > > > > > So, all of the routers would have to participate in signalling to > > > know whether the flow label was used for DiffServ, IntServ, etc.? > > > > > > Or, it would just work to use the flow label for load balancing, > > > even it it contained a DiffServ or IntServ value, instead of > > > labeling a microflow? > > > >How DiffServ and IntServ work with the flow label is yet to be > >determined. All I am saying is that the current spec does not > >preclude any of the functions mentioned above. Isn't that the > >point of the draft? > > > >As Matt said, the host knows best what a flow is. Whether that > >flow gets signaled to routers for special handling or not is > >outside the scope of this doc. > > > >Brian -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment at the IBM Zurich Laboratory, Switzerland -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 13 00:01:32 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8D71Vwf009384; Fri, 13 Sep 2002 00:01:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8D71Vj4009383; Fri, 13 Sep 2002 00:01:31 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8D71Owf009376 for ; Fri, 13 Sep 2002 00:01:24 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8D71SEV000640 for ; Fri, 13 Sep 2002 00:01:28 -0700 (PDT) Received: from mail-gw2.hursley.ibm.com (mail-gw2.hursley.ibm.com [194.196.110.19]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA00679 for ; Fri, 13 Sep 2002 01:01:22 -0600 (MDT) Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw2.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.10) id 17pkS9-0007PV-00; Fri, 13 Sep 2002 08:01:21 +0100 Received: from [9.20.45.103] (helo=sp15en17.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.10) id 17pkS9-0007PQ-00; Fri, 13 Sep 2002 08:01:21 +0100 Received: from hursley.ibm.com (dhcp23-199.zurich.ibm.com [9.4.23.199]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id IAA26690; Fri, 13 Sep 2002 08:01:19 +0100 Message-ID: <3D818D4F.EE4B0B46@hursley.ibm.com> Date: Fri, 13 Sep 2002 09:01:35 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com CC: alh-ietf@tndh.net, jarno.rajahalme@nokia.com Subject: Tony's text comments [Re: Flow label draft issues & new text] References: <01b901c25a8f$1fcce4e0$011aa8c0@eagleswings> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tony's comments on the text seem valid to me. Brian Tony Hain wrote: ... > I do have comments on the text. I would like to see the following > changed from: > 4. Flow Labeling Requirements > (4) The source SHOULD assign each new transport connection (e.g. > TCP, SCTP) to a new flow. > > to: > (4) The source SHOULD assign each unrelated transport connection (e.g. > TCP, SCTP) to a new flow. > > This would keep it from conflicting with (3). > > 5. Flow State Establishment Requirements > ... > To enable co-existence of different methods in IPv6 nodes, the > methods MUST meet the following basic requirements: > ... > (3) The IPv6 node facility keeping track of the Flow Label and the > associated Source and Destination Addresses MUST be utilized > when assigning Flow Label values to new flows (see section 4 > above). > > That wording seems awkward, how about: > (3) The IPv6 source node MUST provide a facility for keeping track > of the Flow Label values associated with particular Source and > Destination Addresses for use when assigning Flow Label to new flows > (see section 4 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 Fri Sep 13 03:14:34 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8DAEXwf009931; Fri, 13 Sep 2002 03:14:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8DAEXxw009930; Fri, 13 Sep 2002 03:14:33 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8DAERwf009923 for ; Fri, 13 Sep 2002 03:14:27 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8DAEUEV021919 for ; Fri, 13 Sep 2002 03:14:31 -0700 (PDT) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA22424 for ; Fri, 13 Sep 2002 04:14:25 -0600 (MDT) From: jarno.rajahalme@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g8DAEbZ07412 for ; Fri, 13 Sep 2002 13:14:37 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 13 Sep 2002 13:14:23 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 13 Sep 2002 13:14:23 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Flow label draft issues & new text Date: Fri, 13 Sep 2002 13:14:22 +0300 Message-ID: <009CA59D1752DD448E07F8EB2F91175719815E@esebe004.ntc.nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Flow label draft issues & new text Thread-Index: AcJaqKd43F0XTZ/hSni27AOfpCdRewAZOrcA To: , Cc: , , , , , X-OriginalArrivalTime: 13 Sep 2002 10:14:23.0470 (UTC) FILETIME=[5511E0E0:01C25B0E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g8DAERwf009924 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret Wasserman wrote: > This seems a lot simpler than the current doc, and would allow > routers to make some immediate use of the flow label field to > limit situations where they need to parse into the packet to > find upper-layer ports (parse once, and cache the value based > on src/dst/flow label). > What you described above is equivalent to the "opportunistic" flow set-up mechanism included originally in RFC 1883. The practice was abandoned already in RFC 2460. 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 Fri Sep 13 03:17:14 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8DAHEwf009953; Fri, 13 Sep 2002 03:17:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8DAHE8k009952; Fri, 13 Sep 2002 03:17:14 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8DAH8wf009945 for ; Fri, 13 Sep 2002 03:17:08 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8DAH7PG003168 for ; Fri, 13 Sep 2002 03:17:08 -0700 (PDT) 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 EAA02963 for ; Fri, 13 Sep 2002 04:16:58 -0600 (MDT) From: jarno.rajahalme@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g8DAGsT00725 for ; Fri, 13 Sep 2002 13:16:54 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 13 Sep 2002 13:16:26 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 13 Sep 2002 13:16:27 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Flow label draft issues & new text Date: Fri, 13 Sep 2002 13:16:26 +0300 Message-ID: <009CA59D1752DD448E07F8EB2F911757D31112@esebe004.ntc.nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Flow label draft issues & new text Thread-Index: AcJaj0KQeIE9WRXiQqq4fGohpJsKSQAf0TBg To: , , Cc: , , , , X-OriginalArrivalTime: 13 Sep 2002 10:16:27.0054 (UTC) FILETIME=[9EBB4CE0:01C25B0E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g8DAH8wf009946 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tony, I'm ok with both of the text improvements you proposed. Thanks, Jarno > -----Original Message----- > From: ext Tony Hain [mailto:alh-ietf@tndh.net] > Sent: Thursday, September 12, 2002 10:04 PM > To: 'Michael Thomas'; 'Margaret Wasserman' > Cc: 'Brian E Carpenter'; Rajahalme Jarno (NRC/Helsinki); > Erik.Nordmark@Sun.COM; kre@munnari.OZ.AU; narten@us.ibm.com; > ipng@sunroof.eng.sun.com > Subject: RE: Flow label draft issues & new text > > > Michael Thomas wrote: > > ... snip > > > What doesn't work is if there may be non-zero values in > > the flow label > that actually don't label flows. How is a > > load-balancing or load-spreading > router supposed to know > > that this isn't a flow label? > > > > Er, well, it _doesn't_. I guess I just don't > > attach any special meaning to the word "flow"; > > that is, a flow is whatever the host says is a > > flow. If it's bizarre, then well, why should > > the router care? Again, other than maybe gaming > > fair queuing algorithms[*], why do routers > > actually care about what constitutes the > > sematics of the flow? It's really in the host's > > best interest to be network friendly, right? To > > give routers information which increases the > > probability of forwarding its packets in the > > manner it hopes for, right? > > > > ... snip > > Er, but the flow label *is* an element of a > > packet classifier, or rather perhaps a > > replacement for the current method of classifying > > packets. I thought as far as routers are > > concerned, flow label were opaque and that no > > internal semantics were visible. > > > > > Mike is right, as far as middle-boxes are concerned the FL is opaque > unless they have been given specific state to believe otherwise. There > is no reason a load-spreader would have a problem with frequent reuse, > or even all nodes deciding to use the same value for HTTP as > long as it > is basing its decisions on the Src/Dst/FL rather than just the FL. > > > I do have comments on the text. I would like to see the following > changed from: > 4. Flow Labeling Requirements > (4) The source SHOULD assign each new transport connection (e.g. > TCP, SCTP) to a new flow. > > to: > (4) The source SHOULD assign each unrelated transport > connection (e.g. > TCP, SCTP) to a new flow. > > This would keep it from conflicting with (3). > > > 5. Flow State Establishment Requirements > ... > To enable co-existence of different methods in IPv6 nodes, the > methods MUST meet the following basic requirements: > ... > (3) The IPv6 node facility keeping track of the Flow Label and the > associated Source and Destination Addresses MUST be utilized > when assigning Flow Label values to new flows (see section 4 > above). > > That wording seems awkward, how about: > (3) The IPv6 source node MUST provide a facility for keeping track > of the Flow Label values associated with particular Source and > Destination Addresses for use when assigning Flow Label to new flows > (see section 4 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 Fri Sep 13 03:23:39 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8DANdwf010003; Fri, 13 Sep 2002 03:23:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8DANc0T010002; Fri, 13 Sep 2002 03:23:38 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8DANXwf009995 for ; Fri, 13 Sep 2002 03:23:33 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8DANbEV024356 for ; Fri, 13 Sep 2002 03:23:37 -0700 (PDT) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA10465 for ; Fri, 13 Sep 2002 04:23:26 -0600 (MDT) From: jarno.rajahalme@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g8DANNT04874 for ; Fri, 13 Sep 2002 13:23:23 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 13 Sep 2002 13:23:19 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 13 Sep 2002 13:23:20 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Flow label draft issues & new text Date: Fri, 13 Sep 2002 13:23:19 +0300 Message-ID: <009CA59D1752DD448E07F8EB2F91175719815F@esebe004.ntc.nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Flow label draft issues & new text Thread-Index: AcJafldrTXE7xSkJT3KwbPDWuI050gAkGe2A To: , Cc: , , , , X-OriginalArrivalTime: 13 Sep 2002 10:23:20.0337 (UTC) FILETIME=[95114810:01C25B0F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g8DANXwf009996 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I'm taking no position here on whether labeling like presented below should or should not be done, but... Margaret Wasserman wrote: > - All HTTP packets get the same flow label. > > How would this work with a load spreader that is > trying to spread connections between a group > of web servers? > Even if the server farm shared a common "anycast" destination address, the different source address of each host will make the hash of fl/src/dst different. The hash value would remain stable as well, so no problem for this usage. > - The flow label contains a packet classifier. > > This *might* be okay, if values aren't reused too > often, and if a single connection always uses > the same value. > You probably meant diffserv per-hop-behavior-id, but even then the above mentioned hash value would remain stable for the microflow. 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 Fri Sep 13 18:02:46 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8E12jwf013000; Fri, 13 Sep 2002 18:02:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8E12jfu012999; Fri, 13 Sep 2002 18:02:45 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8E12cwf012992 for ; Fri, 13 Sep 2002 18:02:38 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8E12gPG027085 for ; Fri, 13 Sep 2002 18:02:42 -0700 (PDT) Received: from hall.mail.mindspring.net (hall.mail.mindspring.net [207.69.200.60]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA23958 for ; Fri, 13 Sep 2002 19:02:37 -0600 (MDT) Received: from dialup-65.56.121.209.dial1.dallas1.level3.net ([65.56.121.209] helo=ix.netcom.com) by hall.mail.mindspring.net with esmtp (Exim 3.33 #1) id 17q1KA-0005N2-00; Fri, 13 Sep 2002 21:02:14 -0400 Message-ID: <3D82A568.37AD2BE1@ix.netcom.com> Date: Fri, 13 Sep 2002 19:56:41 -0700 From: Jeff Williams Organization: INEGroup Spokesman X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit) MIME-Version: 1.0 To: Pekka Savola CC: Joe Baptista , "DNSO, General Assembly" , ISI IPv6 list <6bone@ISI.EDU>, Internet Architecture Board , "ipng@sunroof.eng.sun.com" , vint Cerf , atlarge discuss list Subject: Re: [ga] Overcoming IPv6 Security Threat References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka and all assembly members or other interested parties, No I was not kidding... Pekka Savola wrote: > On Thu, 12 Sep 2002, Jeff Williams wrote: > > Joe and all assembly members other interested parties, > > > > Thanks Joe for passing this interesting and very accurate article. > > Hmm.. > > > It is good that also Jim FLemings IPv8 got a little well deserved > > attention as well. Kudos to Jim there! > > You must be kidding! > > -- > 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 -- Jeffrey A. Williams Spokesman for INEGroup - (Over 127k members/stakeholders strong!) CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng. Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 214-244-4827 or 972-244-3801 Address: 5 East Kirkwood Blvd. Grapevine Texas 75208 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 14 20:50:22 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8F3oMwf015602; Sat, 14 Sep 2002 20:50:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8F3oMRF015601; Sat, 14 Sep 2002 20:50:22 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8F3oHwf015594 for ; Sat, 14 Sep 2002 20:50:17 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8F3oOPG019907 for ; Sat, 14 Sep 2002 20:50:24 -0700 (PDT) Received: from shen.bol.com.br (shen.bol.com.br [200.221.24.14]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA25611 for ; Sat, 14 Sep 2002 21:50:18 -0600 (MDT) From: rdfreita@bol.com.br Received: from bol.com.br (200.221.24.130) by shen.bol.com.br (5.1.071) id 3D63D22F00803051 for ipng@sunroof.eng.sun.com; Sun, 15 Sep 2002 00:49:31 -0300 Date: Sun, 15 Sep 2002 00:47:58 -0300 Message-Id: Subject: Maturity levels MIME-Version: 1.0 Content-Type: text/plain;charset="iso-8859-1" To: ipng@sunroof.eng.sun.com X-XaM3-API-Version: 2.4.3.4.4 X-SenderIP: 200.192.35.5 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g8F3oHwf015595 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi all I need to know the maturity levels of the following RFC: 2460 – Proposed Standard 2675 – Proposed Standard 1981 - Proposed Standard 3168 – Proposed Standard 2474 - Proposed Standard 2402 - Proposed Standard 2406 - Proposed Standard 2373 - Proposed Standard I searched in http://www.rfc-editor.org/cgi-bin/rfcsearch.pl, but i think i can not believe on it. Please, someone could inform me where can I find the correct (and updated) information ? Thanks __________________________________________________________________________ AcessoBOL, só R$ 9,90! O menor preço do mercado! Assine já! http://www.bol.com.br/acessobol -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 15 10:47:57 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8FHlvwf016709; Sun, 15 Sep 2002 10:47:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8FHlv2u016708; Sun, 15 Sep 2002 10:47:57 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8FHlpwf016701 for ; Sun, 15 Sep 2002 10:47:51 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8FHltEV025314 for ; Sun, 15 Sep 2002 10:47:55 -0700 (PDT) Received: from sun1.spfo.unibo.it (sun1.spfo.unibo.it [137.204.198.2]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA19916 for ; Sun, 15 Sep 2002 10:47:50 -0700 (PDT) Received: (from capitani@localhost) by spfo.unibo.it id TAA24080; Sun, 15 Sep 2002 19:32:48 +0200 (MET DST) Date: Sun, 15 Sep 2002 19:32:48 +0200 (MET DST) From: Gianluca Capitani To: rdfreita@bol.com.br cc: ipng@sunroof.eng.sun.com Subject: Re: Maturity levels In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by sunroof.eng.sun.com id g8FHlpwf016702 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, The updated status of RFC is at link : http://www.rfc-editor.org/rfcxx00.html (eg. rfc2460 is draft standard ecct....) bye , Gianluca C.. On Sun, 15 Sep 2002 rdfreita@bol.com.br wrote: > Hi all > > I need to know the maturity levels of the following RFC: > 2460 – Proposed Standard > 2675 – Proposed Standard > 1981 - Proposed Standard > 3168 – Proposed Standard > 2474 - Proposed Standard > 2402 - Proposed Standard > 2406 - Proposed Standard > 2373 - Proposed Standard > > > > I searched in > http://www.rfc-editor.org/cgi-bin/rfcsearch.pl, but i > think i can not believe on it. > > Please, someone could inform me where can I find the > correct (and updated) information ? > > Thanks > > > > > > > > __________________________________________________________________________ > AcessoBOL, só R$ 9,90! O menor preço do mercado! > Assine já! http://www.bol.com.br/acessobol > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Sep 15 22:37:30 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8G5bTwf018050; Sun, 15 Sep 2002 22:37:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8G5bTiu018049; Sun, 15 Sep 2002 22:37:29 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8G5bOwf018042 for ; Sun, 15 Sep 2002 22:37:24 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8G5bTEV029053 for ; Sun, 15 Sep 2002 22:37:29 -0700 (PDT) Received: from shen.bol.com.br (shen.bol.com.br [200.221.24.14]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA11668 for ; Sun, 15 Sep 2002 23:37:23 -0600 (MDT) From: rdfreita@bol.com.br Received: from bol.com.br (200.221.24.140) by shen.bol.com.br (5.1.071) id 3D63D22F00840AC4 for ipng@sunroof.eng.sun.com; Mon, 16 Sep 2002 02:36:35 -0300 Date: Mon, 16 Sep 2002 02:34:59 -0300 Message-Id: Subject: Transition OSPF for IPV6 MIME-Version: 1.0 Content-Type: text/plain;charset="iso-8859-1" To: ipng@sunroof.eng.sun.com X-XaM3-API-Version: 2.4.3.4.4 X-SenderIP: 200.192.35.5 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g8G5bOwf018043 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi all Is there any RFC concerning to transition to OSPF for IPV6, or documents that reports some experience on doing that ? Thanks Reginaldo __________________________________________________________________________ AcessoBOL, só R$ 9,90! O menor preço do mercado! Assine já! http://www.bol.com.br/acessobol -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 15 23:24:32 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8G6OWwf018127; Sun, 15 Sep 2002 23:24:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8G6OW5p018126; Sun, 15 Sep 2002 23:24:32 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8G6OQwf018119 for ; Sun, 15 Sep 2002 23:24:26 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8G6OWEV007552 for ; Sun, 15 Sep 2002 23:24:32 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA26357 for ; Sun, 15 Sep 2002 23:24:26 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g8G6OKR29469; Mon, 16 Sep 2002 09:24:20 +0300 Date: Mon, 16 Sep 2002 09:24:19 +0300 (EEST) From: Pekka Savola To: rdfreita@bol.com.br cc: ipng@sunroof.eng.sun.com Subject: Re: Transition OSPF for 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, 16 Sep 2002 rdfreita@bol.com.br wrote: > Is there any RFC concerning to transition to OSPF for > IPV6, No, unless you're interested at the OSPFv3 base spec itself, RFC2740. > or documents that reports some experience on doing > that ? Not that I'm aware of. But it really does not matter, as for all practical purposes, OSPFv2 and OSPFv3 are two different protocols -- so it really isn't an issue of transitioning but beginning to use another IGP for IPv6. -- 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 Sep 16 11:44:28 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8GIiSwf020898; Mon, 16 Sep 2002 11:44:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8GIiR0n020897; Mon, 16 Sep 2002 11:44:27 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8GIiMwf020890 for ; Mon, 16 Sep 2002 11:44:22 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8GIiREV008330 for ; Mon, 16 Sep 2002 11:44:27 -0700 (PDT) Received: from zcamail03.zca.compaq.com (zcamail03.zca.compaq.com [161.114.32.103]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA01964 for ; Mon, 16 Sep 2002 12:44:21 -0600 (MDT) Received: from mailrelay01.cce.cpqcorp.net (mailrelay01.cce.cpqcorp.net [16.47.68.171]) by zcamail03.zca.compaq.com (Postfix) with ESMTP id E69CF2F97; Mon, 16 Sep 2002 11:44:20 -0700 (PDT) Received: from anw.zk3.dec.com (bwasted.zk3.dec.com [16.140.128.41]) by mailrelay01.cce.cpqcorp.net (Postfix) with ESMTP id 3D61AF07; Mon, 16 Sep 2002 13:44:20 -0500 (CDT) Received: by anw.zk3.dec.com (8.11.1/1.1.22.2/08Sep98-0251PM) id g8GIiJe0001040560; Mon, 16 Sep 2002 14:44:19 -0400 (EDT) Date: Mon, 16 Sep 2002 14:44:19 -0400 (EDT) From: Jack McCann Message-Id: <200209161844.g8GIiJe0001040560@anw.zk3.dec.com> To: narten@us.ibm.com Subject: Re: IESG feedback on draft-ietf-ipngwg-rfc2553bis-06.txt Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas, Comments inline below. I will incorporate this feedback (and feedback from one other reviewer email) and rev the spec one more time. - Jack >From narten@us.ibm.com Tue Sep 3 13:49:39 2002 >To: Jack.McCann@hp.com >Cc: ipng@sunroof.eng.sun.com >Subject: IESG feedback on draft-ietf-ipngwg-rfc2553bis-06.txt >Date: Tue, 03 Sep 2002 13:46:07 -0400 >From: Thomas Narten > >The IESG recently reviewed this document. No major issues, I think. However >the following issues were raised and warrant investigation. Once these >comments are addressed, I expect the IESG to approve the document. > >Comments: > >I only have draft 7 of 1003.1-2001 with me, so maybe some of these >issues are bugs in draft 7. > >note: the above was then followed up with the following: > >I looked at my CD-ROM copy of The Open Group's SUSv3 (their version of >the Austin standard, also 1003.1-2001) and didn't find any differences >from draft 7 on these issues.] > >In the middle of section 3.3, this sentence doesn't make any sense to >me: > > The sin6_flowinfo > field SHOULD be set to zero by an implementation prior to using the > sockaddr_in6 structure by an application on receive operations. > >There's no reference to this in 1003.1-2001, as far as I can tell, and >I don't even really understand what it means - does it mean that the >previously "result only" sockaddr arg to accept() or recvfrom() is now >"value-result", and that a non-zero sin6_flowinfo passed in as the value >has some undesirable semantic? Does it mean that an application should >always say "sin6->sin6_flowinfo = 0" after receiving it from an accept() >or recvfrom()? Good point. After staring at it a bit, I don't think it means either of those things. I think this is intended as a recommendation to the *implementation* (e.g. the kernel) to make sure it does not leave uninitialized garbage in the sin6_flowinfo field of a sockaddr_in6 it is going to give back to the application on a receive operation. I think the word "provided" is missing, that is the sentence should read "...sockaddr_in6 structure provided by an application...". That said: a. I could be wrong about that, I don't know the original intent. b. I think the sentence in question can be safely deleted. c. The use of sin6_flowinfo is rather underspecified. Of the 32 bits, which ones contain the traffic class and which ones contain the flow label? What's in the other 4 bits? Can I use it to set the traffic class and/or flow label for outbound packets (e.g. on a connect(), sendto() or sendmsg()? What is behavior of this field on accept/recvfrom/recvmsg? What is behavior with TCP? What is interaction with IPV6_TCLASS option from rfc2292bis? >In section 3.10, the text was updated to remove the extra prefixed >underscore in the sockaddr_storage definition, but the struct was not. >e.g. the struct has elements like "__ss_pad1" and the text refers to >"_ss_pad1". This is true of all of the struct elements and the >references to them in the comment. Will fix. >There's a similar problem with the definition for systems with an >sa_len field, but there's also a second problem here: the definition of >_SS_PAD2SIZE is incorrect. It needs to add back the sizeof(uint8_t) >as well. (I actually checked this by compiling test programs). >It would seem much simpler to just define _SS_PAD2SIZE as >_SS_MAXSIZE - 2*_SS_ALIGNSIZE, but that would break parallelism with >1003.1-2001 so it's probably best to just add in the sizeof(uint8_t), i.e. > >#define _SS_PAD2SIZE (_SS_MAXSIZE - (sizeof (uint8_t) + sizeof (sa_family_t) + > _SS_PAD1SIZE + _SS_ALIGNSIZE)) > >(This bug isn't in 1003.1-2001 since it doesn't mention sa_len at all) Will fix. >The last paragraph in section 4.4 seems odd; e.g. there's no parallel >wording for or any of the other headers that gain new prototypes >and structs and constants. Is it necessary? Not any more, I will delete it. >Section 6.1 doesn't describe EAI_OVERFLOW as a possible return value >from getaddrinfo(), while 1003.1-2001 does. That was a mistake in 1003.1-2001, getaddrinfo() has no buffer arguments to overflow. I've filed a bug report to try to have it removed from the getaddrinfo() definition in 1003.1-2001. >Conversely, 6.2 describes >EAI_OVERFLOW as a possible return value from getnameinfo(), while >1003.1-2001 doesn't. That was a mistake in 1003.1-2001 and is fixed in the pending Technical Corrigenda 1 to that document. >The first paragraph of the Acks section reads oddly, switching from >Richard to Rich and back again. Maybe just replace "Rich's" with "His" >to avoid it? OK. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 16 11:47:07 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8GIl7wf020920; Mon, 16 Sep 2002 11:47:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8GIl6Zr020919; Mon, 16 Sep 2002 11:47:06 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8GIl1wf020912 for ; Mon, 16 Sep 2002 11:47:01 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8GIl5PG012324 for ; Mon, 16 Sep 2002 11:47:05 -0700 (PDT) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA22912 for ; Mon, 16 Sep 2002 12:46:59 -0600 (MDT) Received: from taynzmail03.nz-tay.cpqcorp.net (taynzmail03.nz-tay.cpqcorp.net [16.47.4.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 885E79275; Mon, 16 Sep 2002 14:46:59 -0400 (EDT) Received: from anw.zk3.dec.com (bwasted.zk3.dec.com [16.140.128.41]) by taynzmail03.nz-tay.cpqcorp.net (Postfix) with ESMTP id E5AC41620; Mon, 16 Sep 2002 14:46:58 -0400 (EDT) Received: by anw.zk3.dec.com (8.11.1/1.1.22.2/08Sep98-0251PM) id g8GIkwP0001040233; Mon, 16 Sep 2002 14:46:58 -0400 (EDT) Date: Mon, 16 Sep 2002 14:46:58 -0400 (EDT) From: Jack McCann Message-Id: <200209161846.g8GIkwP0001040233@anw.zk3.dec.com> To: hessu@cs.tut.fi, ipng@sunroof.eng.sun.com Subject: Re: Comments on draft-ietf-ipngwg-rfc2553bis-06.txt Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Heikki, Thank you for your comments, my responses inline below. I'll fix what I can in the final rev of the spec. - Jack >From owner-ipng@sunroof.eng.sun.com Wed Sep 4 08:53:02 2002 >To: ipng@sunroof.eng.sun.com >Subject: Comments on draft-ietf-ipngwg-rfc2553bis-06.txt >From: Heikki Vatiainen >Date: 04 Sep 2002 15:43:40 +0300 > >Here are my comments about draft-ietf-ipngwg-rfc2553bis-06.txt > >On many pages, null (the C null pointer constant) is sometimes written >as null and sometimes NULL. Also, the ASCII NUL terminated C strings >have different written forms. Currently the text has at least these >variants of null/NULL: > > o NULL pointer > o NULL > o null pointer > o null terminated name > o null-terminated string > o null byte > o null > >For clarity, maybe all C null pointers could be written as "NULL". >When ASCII NUL byte terminated C strings are discussed, they could all >be written as "null-terminated string(s)". I'll see what I can do about this. >On top of page 12, there is one instance of _SS_ALIGNMENT. This, I >suppose, should be _SS_ALIGNSIZE. Will fix. >Also on page 12, in the example about struct sockaddr_storage on >systems with "sa_len", "#define _SS_PAD2SIZE" does not include sizeof >(uint8_t), the size of "ss_len" member. Will fix. >On page 18, the printf seems to lack at least \n" and possibly more. Will fix. >On page 19, the second paragraph from bottom, inet_ntop() is used as >an example of a function using standard IPv6 text forms. Should this >be inet_pton() since it, just like getaddrinfo, takes in character >strings (page 26, first paragraph)? Ah, this is cut/paste from 1003.1-2001, where "inet_ntop()" refers to the reference page which defines both inet_ntop() and inet_pton(). I think we can reword as you suggest. >On page 22, it is said that freeaddrinfo() frees addrinfo lists with >"any additional storage associated with those structures". I take this >additional storage is memory pointed by ai_addr and ai_canonname >(unless ai_canonname points to the same place as nodename parameter)? >Maybe the wording could be made explicit that after freeaddrinfo() is >called, the caller MUST not refer to memory pointed by ai_addr members >of freed addrinfo structures. The same applies to ai_cannoname if >ai_canonname did not point to nodename. You take it correctly (except the part about ai_cannoname pointing to nodename, that should not happen, getaddrinfo can't assume that memory won't be freed or otherwise reused by the caller). -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 16 22:46:42 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8H5kfwf023188; Mon, 16 Sep 2002 22:46:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8H5kfnf023187; Mon, 16 Sep 2002 22:46:41 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8H5kZwf023180 for ; Mon, 16 Sep 2002 22:46:36 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8H5kbPG019770 for ; Mon, 16 Sep 2002 22:46:37 -0700 (PDT) Received: from network2.cs.usm.my (network2.cs.usm.my [161.142.8.104]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA03805 for ; Mon, 16 Sep 2002 23:46:30 -0600 (MDT) Received: from zaiyatul (unknown [10.207.130.244]) by network2.cs.usm.my (Postfix) with SMTP id C927DF3C1 for ; Tue, 17 Sep 2002 13:46:24 +0800 (MYT) Message-ID: <000901c25e0e$4ecdabd0$f482cf0a@zaiyatul> From: "Zaiyatul Hijah" To: References: Subject: IPv6 protocol analyzer Date: Tue, 17 Sep 2002 13:51:46 +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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi all, I'm currently developing IPv6 protocol analyzer for my research project. Just want to know your opinion, is there any problem in analyzing IPv6 packet currently or is there any specific RFC that I can refer to for the good of my research. thanks -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 17 05:02:09 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8HC29wf023793; Tue, 17 Sep 2002 05:02:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8HC29I7023792; Tue, 17 Sep 2002 05:02:09 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8HC22wf023784 for ; Tue, 17 Sep 2002 05:02:02 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8HC27PG014481 for ; Tue, 17 Sep 2002 05:02:07 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA26662 for ; Tue, 17 Sep 2002 06:02:01 -0600 (MDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11271; Tue, 17 Sep 2002 08:00:14 -0400 (EDT) Message-Id: <200209171200.IAA11271@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-addr-arch-v3-10.txt Date: Tue, 17 Sep 2002 08:00:14 -0400 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 IP Version 6 Working Group Working Group of the IETF. Title : IP Version 6 Addressing Architecture Author(s) : B. Hinden, S. Deering Filename : draft-ietf-ipngwg-addr-arch-v3-10.txt Pages : 26 Date : 2002-9-16 This specification defines the addressing architecture of the IP Version 6 protocol [IPV6]. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses. This document obsoletes RFC-2373 'IP Version 6 Addressing Architecture'. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-addr-arch-v3-10.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-addr-arch-v3-10.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-addr-arch-v3-10.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: <2002-9-16152002.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-addr-arch-v3-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-addr-arch-v3-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-9-16152002.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 Wed Sep 18 12:42:56 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8IJguwf004833; Wed, 18 Sep 2002 12:42:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8IJgtJF004832; Wed, 18 Sep 2002 12:42:55 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8IJgowf004825 for ; Wed, 18 Sep 2002 12:42:50 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8IJguPG018240 for ; Wed, 18 Sep 2002 12:42:56 -0700 (PDT) Received: from zcamail04.zca.compaq.com (zcamail04.zca.compaq.com [161.114.32.104]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA19078 for ; Wed, 18 Sep 2002 12:42:51 -0700 (PDT) Received: from mailrelay01.cac.cpqcorp.net (mailrelay01.cac.cpqcorp.net [16.47.132.152]) by zcamail04.zca.compaq.com (Postfix) with ESMTP id 7B9C726CF; Wed, 18 Sep 2002 12:42:51 -0700 (PDT) Received: from anw.zk3.dec.com (bwasted.zk3.dec.com [16.140.128.41]) by mailrelay01.cac.cpqcorp.net (Postfix) with ESMTP id BC304BA5; Wed, 18 Sep 2002 12:42:50 -0700 (PDT) Received: by anw.zk3.dec.com (8.11.1/1.1.22.2/08Sep98-0251PM) id g8IJgoi0000880219; Wed, 18 Sep 2002 15:42:50 -0400 (EDT) Date: Wed, 18 Sep 2002 15:42:50 -0400 (EDT) From: Jack McCann Message-Id: <200209181942.g8IJgoi0000880219@anw.zk3.dec.com> To: hessu@cs.tut.fi, ipng@sunroof.eng.sun.com Subject: Re: Comments on draft-ietf-ipngwg-rfc2553bis-06.txt Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>On many pages, null (the C null pointer constant) is sometimes written >>as null and sometimes NULL. Also, the ASCII NUL terminated C strings >>have different written forms. Currently the text has at least these >>variants of null/NULL: >> >> o NULL pointer >> o NULL >> o null pointer >> o null terminated name >> o null-terminated string >> o null byte >> o null >> >>For clarity, maybe all C null pointers could be written as "NULL". >>When ASCII NUL byte terminated C strings are discussed, they could all >>be written as "null-terminated string(s)". > >I'll see what I can do about this. Upon further reflection, I'd like to leave the null/NULL usage as is. Most of it is taken verbatim from the IEEE/OpenGroup/ISO standard, that would be the place to fix it. And in all cases I believe the meaning is clear (NULL pointer vs. null-terminated string). - Jack -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 18 15:26:50 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8IMQnwf005830; Wed, 18 Sep 2002 15:26:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8IMQnFv005829; Wed, 18 Sep 2002 15:26:49 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8IMQfwf005821 for ; Wed, 18 Sep 2002 15:26:42 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8IMQkPG027262 for ; Wed, 18 Sep 2002 15:26:47 -0700 (PDT) Received: from starfruit.itojun.org (pixsv201.isi.com [192.73.222.252]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA10037 for ; Wed, 18 Sep 2002 16:26:31 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id D2BC17B9; Thu, 19 Sep 2002 07:26:14 +0900 (JST) To: hinden@iprg.nokia.com Cc: ipng@sunroof.eng.sun.com Subject: draft-ietf-ipngwg-addr-arch-v3-10.txt 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 From: Jun-ichiro itojun Hagino Date: Thu, 19 Sep 2002 07:26:14 +0900 Message-Id: <20020918222614.D2BC17B9@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk based on v6ops interim meeting discussion, it seems that there are fair amount of consensus that IPv4 mapped address on wire is harmful (causes security drawbacks). draft-itojun-v6ops-v4mapped-harmful-00.txt so, i would like to ask you to update draft-ietf-ipngwg-addr-arch-v3-10 section 2.5.5, to: - constrain use of IPv4 mapped address to IEEE Std 1003.1 (RFC2553) API, and that API only. IPv4 mapped address must not appear on wire, in any of IPv6 header fields, extension header fields, or payloads also, please consider the following too: - remove IPv4 compatible IPv6 addrses, as it is no longer used in draft-ietf-ngtrans-mech-v2-00.txt itojun (as the author of the draft, not as co-chair of v6ops) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 19 02:44:46 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8J9ikwf007995; Thu, 19 Sep 2002 02:44:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8J9ikO2007994; Thu, 19 Sep 2002 02:44:46 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8J9iewf007987 for ; Thu, 19 Sep 2002 02:44:40 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8J9ijPG012537 for ; Thu, 19 Sep 2002 02:44:45 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.97.6]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA21433 for ; Thu, 19 Sep 2002 02:44:22 -0700 (PDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g8J9gT309551; Thu, 19 Sep 2002 16:43:04 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g8J9fhK28809; Thu, 19 Sep 2002 16:42:16 +0700 (ICT) From: Robert Elz To: Jun-ichiro itojun Hagino cc: hinden@iprg.nokia.com, ipng@sunroof.eng.sun.com Subject: Re: draft-ietf-ipngwg-addr-arch-v3-10.txt In-Reply-To: <20020918222614.D2BC17B9@starfruit.itojun.org> References: <20020918222614.D2BC17B9@starfruit.itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 19 Sep 2002 16:41:42 +0700 Message-ID: <28807.1032428502@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 19 Sep 2002 07:26:14 +0900 From: Jun-ichiro itojun Hagino Message-ID: <20020918222614.D2BC17B9@starfruit.itojun.org> | IPv4 mapped address must not appear on wire, | in any of IPv6 header fields, extension header fields, or payloads I'm sure you didn't really mean that, as that would be going way too far. That is, you aren't seriously prohibiting any data that happens to be 80 bits of zeroes, followed by 16 bits of ones, followed by 32 bits of something else, from ever appearing in a packet payload are you? Or even as a data pattern that might happen to occur in some IP header (perhaps encryption data in the ESP header). I have no problems with prohibiting them in address fields in IPv6 headers ("the" IPv6 header, and the others that contain addresses), but anywhere else, the IPv6 address architecture doc has no business treading. So, make that "in any address fields of the IPv6 header, or extension headers" 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 Sep 19 06:57:37 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8JDvbwf008821; Thu, 19 Sep 2002 06:57:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8JDvbqO008820; Thu, 19 Sep 2002 06:57:37 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8JDvVwf008813 for ; Thu, 19 Sep 2002 06:57:31 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8JDvZMq014384 for ; Thu, 19 Sep 2002 06:57:35 -0700 (PDT) Received: from zcamail05.zca.compaq.com (zcamail05.zca.compaq.com [161.114.32.105]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA23667 for ; Thu, 19 Sep 2002 06:57:30 -0700 (PDT) Received: from taynzmail03.nz-tay.cpqcorp.net (taynzmail03.nz-tay.cpqcorp.net [16.47.4.103]) by zcamail05.zca.compaq.com (Postfix) with ESMTP id D1E652830; Thu, 19 Sep 2002 06:57:29 -0700 (PDT) Received: from hp.com (whitestar.zk3.dec.com [16.140.64.49]) by taynzmail03.nz-tay.cpqcorp.net (Postfix) with ESMTP id 0FF87C53; Thu, 19 Sep 2002 09:57:29 -0400 (EDT) Message-ID: <3D89D7C8.4060504@hp.com> Date: Thu, 19 Sep 2002 09:57:28 -0400 From: Vladislav Yasevich Organization: Hewlett Packard User-Agent: Mozilla/5.0 (X11; U; OSF1 alpha; en-US; rv:0.9.9) Gecko/20020318 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jun-ichiro itojun Hagino Cc: hinden@iprg.nokia.com, ipng@sunroof.eng.sun.com Subject: Re: draft-ietf-ipngwg-addr-arch-v3-10.txt References: <20020918222614.D2BC17B9@starfruit.itojun.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jun-ichiro itojun Hagino wrote: > based on v6ops interim meeting discussion, it seems that there are fair > amount of consensus that IPv4 mapped address on wire is harmful (causes > security drawbacks). > draft-itojun-v6ops-v4mapped-harmful-00.txt > > so, i would like to ask you to update draft-ietf-ipngwg-addr-arch-v3-10 > section 2.5.5, to: > - constrain use of IPv4 mapped address to IEEE Std 1003.1 (RFC2553) API, > and that API only. IPv4 mapped address must not appear on wire, > in any of IPv6 header fields, extension header fields, or payloads I disagree. First off all, "must not" is way too strong of a requirement. If someone understands all the potential harmfull effects and is prepared to deal with them, then the addresses can be allowed. Secondly, I don't think that the addressing architecture should forbid the use of the address in an extension header. That is for the extension header to define. -vlad -- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Vladislav Yasevich Tru64 UNIX - IPv6 Project Lead Hewlett Packard Tel: (603) 884-1079 Nashua, NH 03062 ZKO3-3/T07 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 19 07:05:26 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8JE5Qwf008851; Thu, 19 Sep 2002 07:05:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8JE5Pu0008850; Thu, 19 Sep 2002 07:05:25 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8JE5Kwf008843 for ; Thu, 19 Sep 2002 07:05:20 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8JE5NPG021915 for ; Thu, 19 Sep 2002 07:05:23 -0700 (PDT) Received: from mercury.lss.emc.com ([168.159.40.77]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA25000 for ; Thu, 19 Sep 2002 08:05:13 -0600 (MDT) Received: by mercury.lss.emc.com with Internet Mail Service (5.5.2653.19) id ; Thu, 19 Sep 2002 10:03:40 -0400 Message-ID: <33CE6457C7003A478381BCD0B584DEC55EAD09@srmoon> From: "sasson, shuki" To: ipng@sunroof.eng.sun.com Subject: IPv6 protocol switch implementation. Date: Thu, 19 Sep 2002 10:01:56 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g8JE5Kwf008844 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi all, we are designing an IPv6 stack for one of our product. We observed the Free BSD code and came across the following phenomena: The Free BSD code uses the same switch to call the call back of the protocol themselves (like TCP,UDP) and also for processing header options (like Fragmentation). My question is: 1. Can we make the assumption that the IPv6 option header numbers and the protocol numbers are aligned (meaning there is no and there will be no overlap) and use the very same trick? (If the answer is No then I bet a lot of IPv6 implementations out there have a buggy design...) 2. The same question for IPv4, specifically since IPSEC uses option header too. Thanks for your answer, Shuki Sasson Principal Engineer, Network Storage Group EMC² where information lives Phone: 508 305 8515 FaxNo: 508 435 8901 Pager: 877 919 0794 Email: sasson_shuki@emc.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 Sep 19 07:13:34 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8JEDYwf008911; Thu, 19 Sep 2002 07:13:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8JEDXnx008910; Thu, 19 Sep 2002 07:13:33 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8JEDSwf008898 for ; Thu, 19 Sep 2002 07:13:28 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8JEDVPG025298 for ; Thu, 19 Sep 2002 07:13:32 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.97.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA03426 for ; Thu, 19 Sep 2002 07:12:56 -0700 (PDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g8JECE309183; Thu, 19 Sep 2002 21:12:19 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g8JEBuK00982; Thu, 19 Sep 2002 21:11:59 +0700 (ICT) From: Robert Elz To: "sasson, shuki" cc: ipng@sunroof.eng.sun.com Subject: Re: IPv6 protocol switch implementation. In-Reply-To: <33CE6457C7003A478381BCD0B584DEC55EAD09@srmoon> References: <33CE6457C7003A478381BCD0B584DEC55EAD09@srmoon> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Date: Thu, 19 Sep 2002 21:11:56 +0700 Message-ID: <980.1032444716@munnari.OZ.AU> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g8JEDSwf008899 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 19 Sep 2002 10:01:56 -0400 From: "sasson, shuki" Message-ID: <33CE6457C7003A478381BCD0B584DEC55EAD09@srmoon> | 1. Can we make the assumption that the IPv6 option header numbers and the | protocol numbers are aligned (meaning there is no and there will be no | overlap) and use the very same trick? No trick... those numbers are assigned from the same number space, so yes, you can make that assumption. If you like, think of TCP/UDP/... as being just other IPv6 extension headers (except ignorant ones that don't have a next header field...) | 2. The same question for IPv4, specifically since IPSEC uses option header | too. Same number space, IPv4 & IPv6 share that one. So, same answer. 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 Sep 19 07:31:36 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8JEVawf008986; Thu, 19 Sep 2002 07:31:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8JEVaDV008985; Thu, 19 Sep 2002 07:31:36 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8JEVUwf008978 for ; Thu, 19 Sep 2002 07:31:30 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8JEVYMq025621 for ; Thu, 19 Sep 2002 07:31:34 -0700 (PDT) Received: from mms1.broadcom.com (mms1.broadcom.com [63.70.210.58]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with SMTP id HAA15951 for ; Thu, 19 Sep 2002 07:31:29 -0700 (PDT) Received: from 63.70.210.1 by mms1.broadcom.com with ESMTP (Broadcom MMS-1 SMTP Relay (MMS v4.7);); Thu, 19 Sep 2002 07:31:01 -0700 X-Server-Uuid: 1e1caf3a-b686-11d4-a6a3-00508bfc9ae5 Received: from mail-sj1-1.sj.broadcom.com (mail-sj1-1.sj.broadcom.com [10.16.128.231]) by mon-irva-11.broadcom.com (8.9.1/8.9.1) with ESMTP id HAA15324 for ; Thu, 19 Sep 2002 07:31:26 -0700 (PDT) Received: from ltir001720 (dhcp-240-4-194.broadcom.com [10.240.4.194]) by mail-sj1-1.sj.broadcom.com (8.12.4/8.12.4/SSM) with SMTP id g8JEVQWG021788 for ; Thu, 19 Sep 2002 07:31: 26 -0700 (PDT) From: "Guru yeleswarapu" To: ipng@sunroof.eng.sun.com Subject: IPv6 protocol usage Date: Thu, 19 Sep 2002 07:33:16 -0700 Message-ID: <000001c25fe9$7df9d960$c204f00a@ltir001720.sj.broadcom.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <33CE6457C7003A478381BCD0B584DEC55EAD09@srmoon> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 X-WSS-ID: 1197002F1008675-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, We are a chip company and looking at embedding ipv6 into our chip. We are looking at the need of doing that by exploring who implemented in what areas, how much is in use etc.,? I appreciate if some one can throw light on what companies have already implemented and how much efficinet it is from IPv4 and and related pointers Thanks in advance Gurumurthy Yeleswarapu -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 19 07:56:36 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8JEuZwf009232; Thu, 19 Sep 2002 07:56:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8JEuZkU009231; Thu, 19 Sep 2002 07:56:35 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8JEuSwf009224 for ; Thu, 19 Sep 2002 07:56:28 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8JEuWMq006249 for ; Thu, 19 Sep 2002 07:56:32 -0700 (PDT) Received: from starfruit.itojun.org (pixsv201.isi.com [192.73.222.252]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA29042 for ; Thu, 19 Sep 2002 08:56:27 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id E3B547BB; Thu, 19 Sep 2002 23:56:22 +0900 (JST) To: Vladislav Yasevich Cc: hinden@iprg.nokia.com, ipng@sunroof.eng.sun.com In-reply-to: Vladislav.Yasevich's message of Thu, 19 Sep 2002 09:57:28 -0400. <3D89D7C8.4060504@hp.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: draft-ietf-ipngwg-addr-arch-v3-10.txt From: Jun-ichiro itojun Hagino Date: Thu, 19 Sep 2002 23:56:22 +0900 Message-Id: <20020919145622.E3B547BB@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >I disagree. First off all, "must not" is way too strong of a >requirement. If someone understands all the potential >harmfull effects and is prepared to deal with them, then >the addresses can be allowed. i'm not optimitic about it. >Secondly, I don't think that the addressing architecture should >forbid the use of the address in an extension header. That is >for the extension header to define. in which kind of extension header IPv4 mapped address make sense? certainly not the extension header. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Sep 19 08:24:47 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8JFOlwf009430; Thu, 19 Sep 2002 08:24:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8JFOk6E009429; Thu, 19 Sep 2002 08:24:46 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8JFOewf009422 for ; Thu, 19 Sep 2002 08:24:40 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8JFOjPG023105 for ; Thu, 19 Sep 2002 08:24:45 -0700 (PDT) Received: from ztxmail05.ztx.compaq.com (ztxmail05.ztx.compaq.com [161.114.1.209]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA24547 for ; Thu, 19 Sep 2002 08:24:40 -0700 (PDT) Received: from mailrelay01.cce.cpqcorp.net (mailrelay01.cce.cpqcorp.net [16.47.68.171]) by ztxmail05.ztx.compaq.com (Postfix) with ESMTP id C5C8B44FB; Thu, 19 Sep 2002 10:24:39 -0500 (CDT) Received: from hp.com (whitestar.zk3.dec.com [16.140.64.49]) by mailrelay01.cce.cpqcorp.net (Postfix) with ESMTP id DF221225E; Thu, 19 Sep 2002 10:24:38 -0500 (CDT) Message-ID: <3D89EC36.2010103@hp.com> Date: Thu, 19 Sep 2002 11:24:38 -0400 From: Vladislav Yasevich Organization: Hewlett Packard User-Agent: Mozilla/5.0 (X11; U; OSF1 alpha; en-US; rv:0.9.9) Gecko/20020318 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jun-ichiro itojun Hagino Cc: hinden@iprg.nokia.com, ipng@sunroof.eng.sun.com Subject: Re: draft-ietf-ipngwg-addr-arch-v3-10.txt References: <20020919145622.E3B547BB@starfruit.itojun.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jun-ichiro itojun Hagino wrote: >>Secondly, I don't think that the addressing architecture should >>forbid the use of the address in an extension header. That is >>for the extension header to define. > > > in which kind of extension header IPv4 mapped address make sense? > certainly not the extension header. > > itojun There is no point forbidding it from the Destination Options as one example. Some new option at some point in time might want to use a mapped address. There should be a specific prohibition on it. Additionally (and what I was trying to say before), the addressing architecture does not and should not talk about extension header and what's permitted in them. -vlad -- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Vladislav Yasevich Tru64 UNIX - IPv6 Project Lead Hewlett Packard Tel: (603) 884-1079 Nashua, NH 03062 ZKO3-3/T07 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 19 08:43:47 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8JFhkwf009768; Thu, 19 Sep 2002 08:43:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8JFhk9u009767; Thu, 19 Sep 2002 08:43:46 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8JFhbwf009751 for ; Thu, 19 Sep 2002 08:43:37 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8JFhgMq025353 for ; Thu, 19 Sep 2002 08:43:42 -0700 (PDT) Received: from starfruit.itojun.org (pixsv201.isi.com [192.73.222.252]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA16380 for ; Thu, 19 Sep 2002 09:43:37 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 19A677BB; Fri, 20 Sep 2002 00:43:33 +0900 (JST) To: Vladislav Yasevich Cc: hinden@iprg.nokia.com, ipng@sunroof.eng.sun.com In-reply-to: Vladislav.Yasevich's message of Thu, 19 Sep 2002 11:24:38 -0400. <3D89EC36.2010103@hp.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: draft-ietf-ipngwg-addr-arch-v3-10.txt From: Jun-ichiro itojun Hagino Date: Fri, 20 Sep 2002 00:43:33 +0900 Message-Id: <20020919154333.19A677BB@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Jun-ichiro itojun Hagino wrote: >>>Secondly, I don't think that the addressing architecture should >>>forbid the use of the address in an extension header. That is >>>for the extension header to define. >> in which kind of extension header IPv4 mapped address make sense? >> certainly not the extension header. >There is no point forbidding it from the Destination Options as >one example. Some new option at some point in time might want >to use a mapped address. There should be a specific prohibition >on it. what for? i don't see any valid use of it. >Additionally (and what I was trying to say before), the addressing >architecture does not and should not talk about extension header and >what's permitted in them. i'd like to leave it to authors/ipv6wg chairs. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Sep 19 09:11:14 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8JGBDwf010121; Thu, 19 Sep 2002 09:11:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8JGBDPZ010120; Thu, 19 Sep 2002 09:11:13 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8JGB7wf010113 for ; Thu, 19 Sep 2002 09:11:07 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8JGBCMq009593 for ; Thu, 19 Sep 2002 09:11:12 -0700 (PDT) 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 KAA25437 for ; Thu, 19 Sep 2002 10:11:06 -0600 (MDT) 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 JAA24200; Thu, 19 Sep 2002 09:11:06 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g8JGB5k05114; Thu, 19 Sep 2002 09:11:05 -0700 X-mProtect: <200209191611> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (192.73.222.206, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpd2N2KA7; Thu, 19 Sep 2002 09:11:03 PDT Message-Id: <4.3.2.7.2.20020919090914.0274acc0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 19 Sep 2002 09:10:52 -0700 To: "Guru yeleswarapu" From: Bob Hinden Subject: Re: IPv6 protocol usage Cc: ipng@sunroof.eng.sun.com In-Reply-To: <000001c25fe9$7df9d960$c204f00a@ltir001720.sj.broadcom.com> References: <33CE6457C7003A478381BCD0B584DEC55EAD09@srmoon> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Guru, There is an implementation page at http://playground.sun.com/ipv6 It not completely up to date, but should get you started. Bob At 07:33 AM 9/19/2002, Guru yeleswarapu wrote: >Hi, >We are a chip company and looking at embedding ipv6 into our chip. >We are looking at the need of doing that by exploring who implemented >in what areas, how much is in use etc.,? > >I appreciate if some one can throw light on what companies have already >implemented and how much efficinet it is from IPv4 and and related pointers > > >Thanks in advance >Gurumurthy Yeleswarapu > >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home 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 Sep 19 10:12:54 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8JHCrwf010501; Thu, 19 Sep 2002 10:12:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8JHCr9e010500; Thu, 19 Sep 2002 10:12:53 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8JHClwf010490 for ; Thu, 19 Sep 2002 10:12:48 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8JHCrMq007364 for ; Thu, 19 Sep 2002 10:12:53 -0700 (PDT) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA14612 for ; Thu, 19 Sep 2002 11:12:48 -0600 (MDT) Received: from mailrelay01.cce.cpqcorp.net (mailrelay01.cce.cpqcorp.net [16.47.68.171]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 9851EB3C for ; Thu, 19 Sep 2002 13:12:47 -0400 (EDT) Received: from hp.com (whitestar.zk3.dec.com [16.140.64.49]) by mailrelay01.cce.cpqcorp.net (Postfix) with ESMTP id E961B230B; Thu, 19 Sep 2002 12:12:46 -0500 (CDT) Message-ID: <3D8A058E.6080403@hp.com> Date: Thu, 19 Sep 2002 13:12:46 -0400 From: Vladislav Yasevich Organization: Hewlett Packard User-Agent: Mozilla/5.0 (X11; U; OSF1 alpha; en-US; rv:0.9.9) Gecko/20020318 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Re: draft-ietf-ipngwg-addr-arch-v3-10.txt References: <20020919145622.E3B547BB@starfruit.itojun.org> <3D89EC36.2010103@hp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk oops... Vladislav Yasevich wrote: > > There is no point forbidding it from the Destination Options as > one example. Some new option at some point in time might want > to use a mapped address. There should be a specific prohibition ^^^^^^ should not > on it. > -- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Vladislav Yasevich Tru64 UNIX - IPv6 Project Lead Hewlett Packard Tel: (603) 884-1079 Nashua, NH 03062 ZKO3-3/T07 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 19 11:47:13 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8JIlDwf010983; Thu, 19 Sep 2002 11:47:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8JIlD2N010982; Thu, 19 Sep 2002 11:47:13 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8JIl8wf010975 for ; Thu, 19 Sep 2002 11:47:08 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8JIlCMq022676 for ; Thu, 19 Sep 2002 11:47:12 -0700 (PDT) Received: from shen.bol.com.br (shen.bol.com.br [200.221.24.14]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA09726 for ; Thu, 19 Sep 2002 11:47:07 -0700 (PDT) From: rdfreita@bol.com.br Received: from bol.com.br (200.221.24.140) by shen.bol.com.br (5.1.071) id 3D63D22F00984729 for ipng@sunroof.eng.sun.com; Thu, 19 Sep 2002 15:46:17 -0300 Date: Thu, 19 Sep 2002 15:44:30 -0300 Message-Id: Subject: IPV6 over MPLS MIME-Version: 1.0 Content-Type: text/plain;charset="iso-8859-1" To: ipng@sunroof.eng.sun.com X-XaM3-API-Version: 2.4.3.4.4 X-SenderIP: 200.192.35.5 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g8JIl8wf010976 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi all I have read the RFCs 3032 and 3270 and it is not clear to me how to implement , impacts, changes of IPV6 over MPLS ? Is there another docummets or RFCs that discuss about IPV6 over MPLS ? Thanks Reginaldo __________________________________________________________________________ Encontre sempre uma linha desocupada com o Discador BOL! http://www.bol.com.br/discador Ainda não tem AcessoBOL? Assine já! http://www.bol.com.br/acessobol -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 19 12:59:42 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8JJxfwf011469; Thu, 19 Sep 2002 12:59:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8JJxfmD011468; Thu, 19 Sep 2002 12:59:41 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8JJxXwf011461 for ; Thu, 19 Sep 2002 12:59:33 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8JJxcMq027439 for ; Thu, 19 Sep 2002 12:59:38 -0700 (PDT) Received: from galamonitor.galactica.it ([212.41.208.251]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA15994 for ; Thu, 19 Sep 2002 13:59:32 -0600 (MDT) Received: from mail pickup service by galamonitor.galactica.it with Microsoft SMTPSVC; Thu, 19 Sep 2002 21:59:21 +0200 Received: from berry.computer.org ([63.84.220.201]) by galactica.it with Microsoft SMTPSVC(5.5.1877.537.53); Thu, 19 Sep 2002 00:39:36 +0200 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by berry.computer.org (Switch-2.2.1/Switch-2.2.1) with ESMTP id U8IM27JX31616 for ; Wed, 18 Sep 2002 15:43:20 -0700 Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA08769; Wed, 18 Sep 2002 15:38:27 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8IMamPk008711; Wed, 18 Sep 2002 15:38:25 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8IMQnwf005830; Wed, 18 Sep 2002 15:26:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8IMQnFv005829; Wed, 18 Sep 2002 15:26:49 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8IMQfwf005821 for ; Wed, 18 Sep 2002 15:26:42 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8IMQkPG027262 for ; Wed, 18 Sep 2002 15:26:47 -0700 (PDT) Received: from starfruit.itojun.org (pixsv201.isi.com [192.73.222.252]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA10037 for ; Wed, 18 Sep 2002 16:26:31 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id D2BC17B9; Thu, 19 Sep 2002 07:26:14 +0900 (JST) To: hinden@iprg.nokia.com Cc: ipng@sunroof.eng.sun.com Subject: draft-ietf-ipngwg-addr-arch-v3-10.txt 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 From: Jun-ichiro itojun Hagino Date: Thu, 19 Sep 2002 07:26:14 +0900 Message-Id: <20020918222614.D2BC17B9@starfruit.itojun.org> X-OriginalArrivalTime: 19 Sep 2002 19:59:21.0984 (UTC) FILETIME=[0BE49800:01C26017] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk based on v6ops interim meeting discussion, it seems that there are fair amount of consensus that IPv4 mapped address on wire is harmful (causes security drawbacks). draft-itojun-v6ops-v4mapped-harmful-00.txt so, i would like to ask you to update draft-ietf-ipngwg-addr-arch-v3-10 section 2.5.5, to: - constrain use of IPv4 mapped address to IEEE Std 1003.1 (RFC2553) API, and that API only. IPv4 mapped address must not appear on wire, in any of IPv6 header fields, extension header fields, or payloads also, please consider the following too: - remove IPv4 compatible IPv6 addrses, as it is no longer used in draft-ietf-ngtrans-mech-v2-00.txt itojun (as the author of the draft, not as co-chair of v6ops) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Sep 19 13:54:01 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8JKs0wf012173; Thu, 19 Sep 2002 13:54:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8JKs0X4012172; Thu, 19 Sep 2002 13:54:00 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8JKrswf012165 for ; Thu, 19 Sep 2002 13:53:54 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8JKs0Mq023438 for ; Thu, 19 Sep 2002 13:54:00 -0700 (PDT) Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA24907 for ; Thu, 19 Sep 2002 14:53:54 -0600 (MDT) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e3.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g8JKojlN013510; Thu, 19 Sep 2002 16:50:45 -0400 Received: from cichlid.adsl.duke.edu (sig-9-65-253-44.mts.ibm.com [9.65.253.44]) by northrelay02.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g8JKoOUv029204; Thu, 19 Sep 2002 16:50:25 -0400 Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.9.3) with ESMTP id g8JKnuI02289; Thu, 19 Sep 2002 13:49:56 -0700 Message-Id: <200209192049.g8JKnuI02289@cichlid.adsl.duke.edu> To: Robert Elz cc: iesg@ietf.org, ipng@sunroof.eng.sun.com Subject: Not Ready for Draft? draft-ietf-ipngwg-addr-arch-v3-09.txt In-Reply-To: Message from Robert Elz of "Tue, 17 Sep 2002 15:22:57 +0700." <13356.1032250977@munnari.OZ.AU> Date: Thu, 19 Sep 2002 13:49:55 -0700 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert Elz writes: > I believe that the IESG is considering publishing > draft-ietf-ipngwg-addr-arch-v3-09.txt > as a Draft Standard. > Before that happens, you should be aware that RFC2026 requires > 4.1.2 Draft Standard > A specification from which at least two independent and interoperable > implementations from different code bases have been developed, and > for which sufficient successful operational experience has been > obtained, may be elevated to the "Draft Standard" level. > [...] > The requirement for at least two independent and interoperable > implementations applies to all of the options and features of the > specification. In cases in which one or more options or features > have not been demonstrated in at least two interoperable > implementations, the specification may advance to the Draft Standard > level only if those options or features are removed. > The IPv6 address architecture contains 2 features for which the > interoperability report (as currently published on the IETF web page) > does not comment at all, let alone show two independent and interoperable > implementations from different code bases. > Those two are the requirement that all interfaces use /64 subnets, As you have pointed out on the mailing list yourself, all link-layer types will need to support 64-bit interface identifiers for stateless address autoconfiguration. And we have Ethernet, FDDI, ATM, etc. that do that just that. So there is ample evidence (and implementations) that interfaces support the use of /64 subnets. What you seem to be saying above, however, is subtly different. Namely, that all interfaces must "use" /64 subnets. Presumably you mean "implement", as implementation reports don't necessarily indicate actual "use". But if this is your argument, I disagree with it. It is not possible (nor does it make sense) that when a spec says X, the implementation report somehow needs to show that no implementations do *not* do X. This line of reasoning would effectively prevent *any* specification from ever advancing to Draft, as one can never be sure that some implementation (or future implementation) does not do X. If it were the case that there was evidence that there were implementations that did not do X, that would be useful input, but would certainly not by itself prevent a spec from going to Draft. > and the requirement that when the 'u' bit is set, the address has been > derived from a globally unique MAC address. I'm not exactly sure what you think needs to be shown here. The addrarch document describes how one creates EUI-64 identifiers and how one sets the corresponding 'u' bit. We have a number of other documents (e.g., IP over Ether) that actually require that implementations do this. There seems to be wide agreement that implementations do in fact do this (in fact, this is indicated in the implementation report up at http://www.ietf.org/IESG/Implementations/address-architecture.txt). Again, your words seem to suggest an even stronger requirement, namely, that there be some way to show that implementations that set the 'u' bit have actually derived their IIDs from an IEEE identifier. I know of no way of doing this. However, I also don't see that as a problem. I suspect that it would be easy to find in many specifications some implementation recommendations where it is not immediately possible to demonstrate that an implementation that sets bits in a certain way has actually been "authorized" to do so. (How does one verify that an implementation is authorized to set the 'u' bit?) What 2026 requires, is that the words describing how to implement something are clear enough to get interoperable implementations from. 2026 does not require that an implementation that sets the bits in a field in a certain way has actually satisfied all the assumptions/requirements for setting the bits in that way. This would be an unrealistic requirement. > Further, all experience suggests that implementors are widely ignoring > those two requirements - which makes them exactly the kinds of fluff > that this part of 2026 is demanding be removed. What is your evidence that *implementors* are widely ignoring these requirements? I am aware of none. > Or, or course, the doc can be republished as a PS, while awaiting > implementation of the features. > In any case, the document, as it is, with the interoperability report > that exists, clearly do not satisfy the requirements of 2026 that would > allow the document to be published as a draft standard. I disagree, as explained above. 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 Thu Sep 19 22:24:32 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8K5OWwf013981; Thu, 19 Sep 2002 22:24:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8K5OVP3013980; Thu, 19 Sep 2002 22:24:31 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8K5OOwf013973 for ; Thu, 19 Sep 2002 22:24:24 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8K5OTPG006076 for ; Thu, 19 Sep 2002 22:24:29 -0700 (PDT) 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 XAA07550 for ; Thu, 19 Sep 2002 23:24:23 -0600 (MDT) Received: from localhost ([3ffe:501:4819:2000:d1e8:7a9:6506:38ae]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g8K5OJt60576; Fri, 20 Sep 2002 14:24:19 +0900 (JST) Date: Fri, 20 Sep 2002 14:24:46 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Michael Hunter Cc: ipng@sunroof.eng.sun.com Subject: Re: 2292bis ip6_rthdr0 flexible array member In-Reply-To: <20020911152942.42f48e0d.michael.hunter@eng.sun.com> References: <20020911152942.42f48e0d.michael.hunter@eng.sun.com> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 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 20000228(IM140) Lines: 39 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk (Sorry for the delayed response) >>>>> On Wed, 11 Sep 2002 15:29:42 -0700, >>>>> Michael Hunter said: > It would be easier to use if a c99 flexible array member was the last > element: > /* Type 0 Routing header */ > struct ip6_rthdr0 { > uint8_t ip6r0_nxt; /* next header */ > uint8_t ip6r0_len; /* length in units of 8 octets */ > uint8_t ip6r0_type; /* always zero */ > uint8_t ip6r0_segleft; /* segments left */ > uint32_t ip6r0_reserved; /* reserved field */ > #if __STDC_VERSION__ >= 199901L > struct in6_addr ip6r0_addr[0]; /* up to 127 addresses */ > #endif > }; Sorry, but I don't think we should incorporate this to the specification. If an application writer assumes the existence of ip6r0_addr, the source code will not compile with a compiler that does not support the flexible array member. However, I don't want to see conditional compilation tricks like this: struct ip6_rthdr0 *r; struct in6_addr *in6; #if __STDC_VERSION__ >= 199901L in6 = &r->ip6r0_addr[0]; #else in6 = (struct in6_addr *)(r + 1); #endif 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 Sep 19 23:40:01 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8K6e1wf014546; Thu, 19 Sep 2002 23:40:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8K6e0Ix014545; Thu, 19 Sep 2002 23:40:00 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8K6dtwf014538 for ; Thu, 19 Sep 2002 23:39:55 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8K6dwMq010252 for ; Thu, 19 Sep 2002 23:39:58 -0700 (PDT) Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA20924 for ; Fri, 20 Sep 2002 00:39:52 -0600 (MDT) Received: from vasuki.india.hp.com (vasuki.india.hp.com [15.10.41.50]) by palrel11.hp.com (Postfix) with ESMTP id 63973600371; Thu, 19 Sep 2002 23:39:47 -0700 (PDT) Received: from india.hp.com (ob41113.india.hp.com [15.10.41.113]) by vasuki.india.hp.com with ESMTP (8.7.1/8.7.3 SMKit7.02) id MAA02490; Fri, 20 Sep 2002 12:12:51 +0530 (IST) Message-ID: <3D8AC2C4.FEBDB289@india.hp.com> Date: Fri, 20 Sep 2002 12:10:04 +0530 From: Hemanth T D Organization: Hewlett Packard India Software Operation X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jun-ichiro itojun Hagino Cc: Vladislav Yasevich , hinden@iprg.nokia.com, ipng@sunroof.eng.sun.com Subject: Re: draft-ietf-ipngwg-addr-arch-v3-10.txt References: <20020919145622.E3B547BB@starfruit.itojun.org> <3D89EC36.2010103@hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Agree 100% with Vlad. v4 mapped address exists to facilitate transition. In a transition scenario one inherits whatever is good or bad in v4 security anyway. IMHO I think we should debate on where to introduce security measures: packet itself (as in this field in the packet should not contain v4 mapped address) or packet processing (do not source route to a given v4 destination unless ...). So I believe there is not good enough reason to forbit the usage of v4 mapped address. Hemanth. Vladislav Yasevich wrote: > > Jun-ichiro itojun Hagino wrote: > >>Secondly, I don't think that the addressing architecture should > >>forbid the use of the address in an extension header. That is > >>for the extension header to define. > > > > > > in which kind of extension header IPv4 mapped address make sense? > > certainly not the extension header. > > > > itojun > > There is no point forbidding it from the Destination Options as > one example. Some new option at some point in time might want > to use a mapped address. There should be a specific prohibition > on it. > > Additionally (and what I was trying to say before), the addressing > architecture does not and should not talk about extension header and > what's permitted in them. > > -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 Fri Sep 20 04:21:53 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8KBLrwf015937; Fri, 20 Sep 2002 04:21:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8KBLrYR015936; Fri, 20 Sep 2002 04:21:53 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8KBLlwf015929 for ; Fri, 20 Sep 2002 04:21:47 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8KBLoPG005137 for ; Fri, 20 Sep 2002 04:21:50 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.97.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA04041 for ; Fri, 20 Sep 2002 05:21:39 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g8KBJr303401; Fri, 20 Sep 2002 18:19:53 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g8KBJdK04584; Fri, 20 Sep 2002 18:19:43 +0700 (ICT) From: Robert Elz To: Thomas Narten cc: iesg@ietf.org, ipng@sunroof.eng.sun.com Subject: Re: Not Ready for Draft? draft-ietf-ipngwg-addr-arch-v3-10.txt In-Reply-To: <200209192049.g8JKnuI02289@cichlid.adsl.duke.edu> References: <200209192049.g8JKnuI02289@cichlid.adsl.duke.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 20 Sep 2002 18:19:39 +0700 Message-ID: <4582.1032520779@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 19 Sep 2002 13:49:55 -0700 From: Thomas Narten Message-ID: <200209192049.g8JKnuI02289@cichlid.adsl.duke.edu> Note: I have updated the version of the draft in the subject line - the -10 draft appeared just after I sent my previous message (which WG members wouldn't have seen as it was sent only to the IESG) | But if this is your argument, I disagree with it. It is not possible | (nor does it make sense) that when a spec says X, the implementation | report somehow needs to show that no implementations do *not* do | X. Of course. I am going to avoid doing a line by line reply to your message, as you seem to be (for whatever reason) ignoring or misconstruing the thrust of my request. I'm going to assume that was because I wasn't clear enough. I thought the issue was fairly obvious, and would be understood by anyone. But it appears not, so this time I will be more blunt. That might make this message seem patronising - that isn't the intent, I'm just not aware of any other way to make the issues clear enough... For now I will ignore the 'u' bit, we can come back to that later, if necessary, and confine myself just to 64 bit IIDs for the rest of this message (which will be long enough without more added on). What draft-ietf-ipngwg-addr-arch-v3-10.txt requires, at the bottom of page 8 (section 2.5.1) is ... For all unicast addresses, except those that start with binary value 000, Interface IDs are required to be 64 bits long and to be constructed in Modified EUI-64 format. Read that carefully (and I'll ignore the 000 case here, that's irrelevant). Interface IDs are required to be 64 bits long no exceptions (ignoring 000), no alternatives, interface identifiers are required to be 64 bits long. Then again, at the bottom of page 10, and onto the top of page 11, in section 2.5.4, the same thing is restated ... All global unicast addresses other than those that start with binary 000 have a 64-bit interface ID field (i.e., n + m = 64), formatted as described in section 2.5.1. Global unicast addresses that start with binary 000 have no such constraint on the size or structure of the interface ID field. That comes after this ascii art showing a global unicast address... The general format for IPv6 global unicast addresses is as follows: | n bits | m bits | 128-n-m bits | +------------------------+-----------+----------------------------+ | global routing prefix | subnet ID | interface ID | +------------------------+-----------+----------------------------+ (which itself is just fine). Again, read what that says ... All global unicast addresses [...] have a 64-bit interface ID field (i.e., n + m = 64) Again, no ambiguity, no alternatives. What my message to the IESG requested, was that either that text be deleted (there may be one or two other references as well - in a message to the WG list a while ago I listed all the changes that should be made, they're all simple deletes), or that the implementation reports show at least 2 implementations of this requirement/feature. Note: to implement this feature, the implementation would have to prohibit any global unicast address (000 excepted...) from having an interface id that was anything other than 64 bits long. Or, from having m+n in the above diagram being any different from 64 (which, of course, is the same thing). There's no other way to implement this feature. Note, this has nothing at all to do with whether an implementation allows the IID to be 64 bits long - there is quite likely other wording in the doc, that I have no problem with at all, that requires implementations to allow IIDs to be 64 bits, so that autoconfig can work. That's all just fine. And so, I did mean "use" not "implement", as if I can use an address that does not have a 64 bit IID (that is, if I can make m+n > 64) then clearly the implementation is not implementing the above feature. That is, the implementation is not requiring that m+n==64, or in other words is not requiring that the IID be 64 bits long exactly. All that is needed to show that the implementation does not implement this particular feature, is to (attempt to) configure an address that has something other than a 64 bit IID. If it works, then the implementation doesn't implement the two paragraphs I quoted, and cannot count as one of the two that do, which is required for this feature to remain in the doc when it advances to DS. As for ... | What is your evidence that *implementors* are widely ignoring these | requirements? I am aware of none. jade# ifconfig fxp0 fxp0: flags=8843 mtu 1500 media: Ethernet 10baseT status: active [link locals and irrelevant cruft deleted] inet6 3ffe:b80:53:1234:2222::1 prefixlen 112 There's one. There, right before your eyes, is a global IPv6 address. that starts with something other than 000, and in which m+n=112 (which is bigger than 64). That is, the IID in this global address is 16 bits, not 64. What's more, it works ... delta$ ping6 -n 3ffe:b80:53:1234:2222::1 PING6(56=40+8+8 bytes) 3ffe:b80:53:181:206:5bff:feda:45ad --> 3ffe:b80:53:1234:2222::1 16 bytes from 3ffe:b80:53:1234:2222::1, icmp_seq=0 hlim=64 time=0.744 ms 16 bytes from 3ffe:b80:53:1234:2222::1, icmp_seq=1 hlim=64 time=0.272 ms Go ahead, try it if you like (but no guaranntees that it will remain configured for very long, as you can guess, this one I just installed as I was typing this message, to demonstrate that it can be done). Hence, this particular implementation has ignored the requirement that all IIDs are "required to be 64 bits long" - hasn't it? What's more, every implementation I have seen also ignores this requirement. Can you point to even one, that doesn't? But, it is not up to me to prove that the feature is widely ignored. What 2026 requires is (from rfc2026 section 4.1.2): The Working Group chair is responsible for documenting the specific implementations which qualify the specification for Draft or Internet Standard status along with documentation about testing of the interoperation of these implementations. That is, the IESG cannot advance a specification to DS, unless the WG chair (using the WG to assist, one would normally assume) has documented at least 2 implementations of every feature (interoperable ones, but that part isn't likely to be an issue here). 2026 is very clear about that. And while one of the reasons for this is to make sure that the language in the doc is clear enough to implement in an interoperable fashion, another reason is to make sure that "fluff" doesn't remain in the specification, that no-one is actually bothering to implement. The two paragraphs I quoted above are quite clearly that kind of fluff. And to be 100% clear, the feature / requirement that I am objecting to, is the one that *requires* every IID to be 64 bits, and nothing else. Not to the (related but different) one that requires implementations to support 64 bit IIDs, which is just fine, and which the interop testing does document (and I have no reason at all to doubt is widely implemented). 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 Sep 20 04:54:58 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8KBsvwf016159; Fri, 20 Sep 2002 04:54:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8KBsvfm016158; Fri, 20 Sep 2002 04:54:57 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8KBsnwf016141 for ; Fri, 20 Sep 2002 04:54:49 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8KBsqPG014179 for ; Fri, 20 Sep 2002 04:54:52 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA21849 for ; Fri, 20 Sep 2002 05:54:46 -0600 (MDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19100; Fri, 20 Sep 2002 07:52:57 -0400 (EDT) Message-Id: <200209201152.HAA19100@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-rfc2553bis-07.txt Date: Fri, 20 Sep 2002 07:52:57 -0400 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 IP Version 6 Working Group Working Group of the IETF. Title : Basic Socket Interface Extensions for IPv6 Author(s) : R. Gilligan, S. Thomson, J. Bound, J. McCann, W. Stevens Filename : draft-ietf-ipngwg-rfc2553bis-07.txt Pages : 31 Date : 2002-9-19 The de facto standard application program interface (API) for TCP/IP applications is the 'sockets' interface. Although this API was developed for Unix in the early 1980s it has also been implemented on a wide variety of non-Unix systems. TCP/IP applications written using the sockets API have in the past enjoyed a high degree of portability and we would like the same portability with IPv6 applications. But changes are required to the sockets API to support IPv6 and this memo describes these changes. These include a new socket address structure to carry IPv6 addresses, new address conversion functions, and some new socket options. These extensions are designed to provide access to the basic IPv6 features required by TCP and UDP applications, including multicasting, while introducing a minimum of change into the system and providing complete compatibility for existing IPv4 applications. Additional extensions for advanced IPv6 features (raw sockets and access to the IPv6 extension headers) are defined in another document [4]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-rfc2553bis-07.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-rfc2553bis-07.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-rfc2553bis-07.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: <2002-9-19154731.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-rfc2553bis-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-rfc2553bis-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-9-19154731.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Sep 20 04:55:04 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8KBt4wf016162; Fri, 20 Sep 2002 04:55:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8KBt4dM016161; Fri, 20 Sep 2002 04:55:04 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8KBstwf016151 for ; Fri, 20 Sep 2002 04:54:55 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8KBswPG014194 for ; Fri, 20 Sep 2002 04:54:58 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA08877 for ; Fri, 20 Sep 2002 04:54:52 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19118; Fri, 20 Sep 2002 07:53:03 -0400 (EDT) Message-Id: <200209201153.HAA19118@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-ipv6-dns-discovery-06.txt Date: Fri, 20 Sep 2002 07:53:03 -0400 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 IP Version 6 Working Group Working Group of the IETF. Title : Well known site local unicast addresses for DNS resolver Author(s) : A. Durand, J. Hagino, D. Thaler Filename : draft-ietf-ipv6-dns-discovery-06.txt Pages : 12 Date : 2002-9-19 This documents specifies a method for nodes to find a DNS resolver with minimum configuration in the network and without running a discovery protocol on the nodes. This method is to be used in last resort, when no other information about the addresses of DNS resolvers is available. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-dns-discovery-06.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-ipv6-dns-discovery-06.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-ipv6-dns-discovery-06.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: <2002-9-19154740.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-dns-discovery-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-dns-discovery-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-9-19154740.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Sep 20 08:35:56 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8KFZtwf016914; Fri, 20 Sep 2002 08:35:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8KFZta6016913; Fri, 20 Sep 2002 08:35:55 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8KFZowf016906 for ; Fri, 20 Sep 2002 08:35:50 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8KFZrPG022899 for ; Fri, 20 Sep 2002 08:35:53 -0700 (PDT) Received: from ztxmail03.ztx.compaq.com (ztxmail03.ztx.compaq.com [161.114.1.207]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA08290 for ; Fri, 20 Sep 2002 09:35:47 -0600 (MDT) Received: from mailrelay01.cac.cpqcorp.net (mailrelay01.cac.cpqcorp.net [16.47.132.152]) by ztxmail03.ztx.compaq.com (Postfix) with ESMTP id 563341C63 for ; Fri, 20 Sep 2002 10:35:47 -0500 (CDT) Received: from anw.zk3.dec.com (bwasted.zk3.dec.com [16.140.128.41]) by mailrelay01.cac.cpqcorp.net (Postfix) with ESMTP id 92D1D1234 for ; Fri, 20 Sep 2002 08:35:46 -0700 (PDT) Received: by anw.zk3.dec.com (8.11.1/1.1.22.2/08Sep98-0251PM) id g8KFZkU0000736832; Fri, 20 Sep 2002 11:35:46 -0400 (EDT) Date: Fri, 20 Sep 2002 11:35:46 -0400 (EDT) From: Jack McCann Message-Id: <200209201535.g8KFZkU0000736832@anw.zk3.dec.com> To: ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-ietf-ipngwg-rfc2553bis-07.txt Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Changes from 2553bis-06 to 2553bis-07, in response to comments from IESG review and on mailing list: - section 3.3 removed the following sentence: The sin6_flowinfo field SHOULD be set to zero by an implementation prior to using the sockaddr_in6 structure by an application on receive operations. - section 3.10 fix typos: _ss_pad1 -> __ss_pad1 _ss_pad2 -> __ss_pad2 _ss_align -> __ss_align _SS_ALIGNMENT -> _SS_ALIGNSIZE - section 3.10 fix _SS_PAD2SIZE calculation for sockaddr with sa_len - section 4.4. delete this sentence: Currently net/if.h doesn't have prototype definitions for functions and it is recommended that these definitions be defined in net/if.h as well as the struct if_nameindex{}. - section 5.3 fix this printf printf("IPV6_V6ONLY set0); - section 6.1 reference inet_pton instead of inet_ntop in this sentence: If the specified address family is AF_INET6 or AF_UNSPEC, standard IPv6 text forms described in inet_ntop() are valid. - section 6.1 clarify associated storage freed by freeaddrinfo includes storage pointed to by ai_canonname and ai_addr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 20 10:03:11 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8KH3Awf017833; Fri, 20 Sep 2002 10:03:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8KH3ABq017832; Fri, 20 Sep 2002 10:03:10 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8KH35wf017825 for ; Fri, 20 Sep 2002 10:03:05 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8KH38PG001913 for ; Fri, 20 Sep 2002 10:03:09 -0700 (PDT) Received: from dot-god.com (d150-250-196.home.cgocable.net [24.150.250.196]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA06302 for ; Fri, 20 Sep 2002 11:03:03 -0600 (MDT) Received: from localhost (baptista@localhost) by dot-god.com (8.11.4/8.11.4) with ESMTP id g8KH30B24895 for ; Fri, 20 Sep 2002 13:03:00 -0400 Date: Fri, 20 Sep 2002 13:02:59 -0400 (EDT) From: Joe Baptista To: Subject: INTERVIEW - why would anyone want to be IPv6 complient Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello: I'm writing an article on why anyone (individual or business) would want to incorporate IPv6 services into their systems. This is a follow up to my earlier article at the following URL: http://www.circleid.com/articles/2533.asp If you can help please drop me a line. Also I am compiling a list of IPv6 providers - if you provide IPv6 services let me know. I have already requested this on nanog and already have a list in process. Cheers Joe Baptista -- Planet Communications & Computing Facility a division of The dot.GOD Registry, Limited -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 20 14:22:06 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8KLM6wf019381; Fri, 20 Sep 2002 14:22:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8KLM63d019380; Fri, 20 Sep 2002 14:22:06 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8KLM0wf019373 for ; Fri, 20 Sep 2002 14:22:00 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8KLM3Mq010620 for ; Fri, 20 Sep 2002 14:22:03 -0700 (PDT) Received: from mms1.broadcom.com (mms1.broadcom.com [63.70.210.58]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with SMTP id OAA02432 for ; Fri, 20 Sep 2002 14:21:57 -0700 (PDT) Received: from 63.70.210.1 by mms1.broadcom.com with ESMTP (Broadcom MMS-1 SMTP Relay (MMS v4.7);); Fri, 20 Sep 2002 14:21:30 -0700 X-Server-Uuid: 1e1caf3a-b686-11d4-a6a3-00508bfc9ae5 Received: from mail-sj1-5.sj.broadcom.com (mail-sj1-5.sj.broadcom.com [10.16.128.236]) by mon-irva-11.broadcom.com (8.9.1/8.9.1) with ESMTP id OAA24132; Fri, 20 Sep 2002 14:21:56 -0700 (PDT) Received: from pcir000997 (dhcpe1-sj1-094 [10.16.65.94]) by mail-sj1-5.sj.broadcom.com (8.12.4/8.12.4/SSF) with SMTP id g8KLLuER021832; Fri, 20 Sep 2002 14:21:56 -0700 (PDT) From: "Guru Yeleswarapu" To: "Joe Baptista" , ipng@sunroof.eng.sun.com Subject: RE: INTERVIEW - why would anyone want to be IPv6 complient Date: Fri, 20 Sep 2002 14:32:17 -0700 Message-ID: <000001c260ed$31de40c0$5e41100a@pcir000997.sj.broadcom.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 Importance: Normal In-Reply-To: X-WSS-ID: 11954ED01303300-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Iam also very much interested in the same. I have just started looking into. I have no information to pass it on right now. I really apprecaite if you could send me your list so far , may be I can adding some stuff to it. Thanks Guru Yeleswarapu > -----Original Message----- > From: owner-ipng@sunroof.eng.sun.com > [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Joe Baptista > Sent: Friday, September 20, 2002 10:03 AM > To: ipng@sunroof.eng.sun.com > Subject: INTERVIEW - why would anyone want to be IPv6 complient > > > > Hello: > > I'm writing an article on why anyone (individual or business) would want > to incorporate IPv6 services into their systems. This is a follow up to > my earlier article at the following URL: > > http://www.circleid.com/articles/2533.asp > > If you can help please drop me a line. > > Also I am compiling a list of IPv6 providers - if you provide IPv6 > services let me know. I have already requested this on nanog and already > have a list in process. > > Cheers > Joe Baptista > > -- > Planet Communications & Computing Facility > a division of The dot.GOD Registry, Limited > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Sep 20 15:23:55 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8KMNtwf019954; Fri, 20 Sep 2002 15:23:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8KMNtKM019952; Fri, 20 Sep 2002 15:23:55 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8KMNmwf019945 for ; Fri, 20 Sep 2002 15:23:48 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8KMNqMq005252 for ; Fri, 20 Sep 2002 15:23:52 -0700 (PDT) Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA03561 for ; Fri, 20 Sep 2002 15:23:42 -0700 (PDT) Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id g8KMNeD25097; Fri, 20 Sep 2002 15:23:40 -0700 (PDT) Message-Id: <200209202223.g8KMNeD25097@gamma.isi.edu> To: IETF-Announce: ; Subject: RFC 3314 on Recommendations for IPv6 in Third Generation Partnership Project (3GPP) Standards Cc: rfc-editor@rfc-editor.org, ipng@sunroof.eng.sun.com From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Fri, 20 Sep 2002 15:23:40 -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3314 Title: Recommendations for IPv6 in Third Generation Partnership Project (3GPP) Standards Author(s): M. Wasserman, Ed. Status: Informational Date: September 2002 Mailbox: mrw@windriver.com Pages: 23 Characters: 48168 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ipv6-3gpp-recommend-02.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3314.txt This document contains recommendations from the Internet Engineering Task Force (IETF) IPv6 Working Group to the Third Generation Partnership Project (3GPP) community regarding the use of IPv6 in the 3GPP standards. Specifically, this document recommends that the 3GPP specify that multiple prefixes may be assigned to each primary PDP context, require that a given prefix must not be assigned to more than one primary PDP context, and allow 3GPP nodes to use multiple identifiers within those prefixes, including randomly generated identifiers. The IPv6 Working Group supports the use of IPv6 within 3GPP and offers these recommendations in a spirit of open cooperation between the IPv6 Working Group and the 3GPP community. Since the original publication of this document as an Internet-Draft, the 3GPP has adopted the primary recommendations of this document. This document is a product of the IP Version 6 Working Group Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <020920152204.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3314 --OtherAccess Content-Type: Message/External-body; name="rfc3314.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <020920152204.RFC@RFC-EDITOR.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 Sun Sep 22 17:34:40 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8N0Ydwf025807; Sun, 22 Sep 2002 17:34:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8N0YdtF025806; Sun, 22 Sep 2002 17:34:39 -0700 (PDT) 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.17.55]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8N0YYwf025799 for ; Sun, 22 Sep 2002 17:34:34 -0700 (PDT) Received: from laphroig (laphroig.Eng.Sun.COM [129.146.85.171]) by jurassic.eng.sun.com (8.12.6+Sun/8.12.6) with SMTP id g8N0YXW5694036 for ; Sun, 22 Sep 2002 17:34:33 -0700 (PDT) Date: Sun, 22 Sep 2002 17:34:32 -0700 From: Michael Hunter To: ipng@sunroof.eng.sun.com Subject: two 2292bis errors Message-Id: <20020922173432.216be897.michael.hunter@eng.sun.com> X-Mailer: Sylpheed version 0.7.6 (GTK+ 1.2.10; sparc-sun-solaris2.10) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In 2292bis (rev 7) there are two errors: 1) ND_OPT_PI_FLAG_ROUTER only shows up in section 15 (summary of new definitions). 2) ip6_ext shows up in section 15 (summary of new definitions) but it is mentioned in the change log as having been removed. There is no text describing it. mph -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 23 09:43:16 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8NGhGwf000266; Mon, 23 Sep 2002 09:43:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8NGhGnr000265; Mon, 23 Sep 2002 09:43:16 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8NGhAwf000256 for ; Mon, 23 Sep 2002 09:43:10 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8NGhEMq001494 for ; Mon, 23 Sep 2002 09:43:14 -0700 (PDT) Received: from tndh.net (evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net [4.65.20.139]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA29310 for ; Mon, 23 Sep 2002 10:43:09 -0600 (MDT) Received: from eagleswings (127.0.0.1) by localhost (127.0.0.1) with [XMail 1.3 (Win32/Ix86) ESMTP Server] id for from ; Mon, 23 Sep 2002 09:43:05 -0700 Reply-To: From: "Tony Hain" To: "'Guru Yeleswarapu'" , "'Joe Baptista'" , Subject: RE: INTERVIEW - why would anyone want to be IPv6 complient Date: Mon, 23 Sep 2002 09:42:57 -0700 Message-ID: <073c01c26320$4608f290$011aa8c0@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <000001c260ed$31de40c0$5e41100a@pcir000997.sj.broadcom.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g8NGhAwf000258 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk For those that may be unaware, if his recent rant on IPv6 security is any indication, Joe is likely baiting you... http://www.kkc.net/baptista/ > -----Original Message----- > From: owner-ipng@sunroof.eng.sun.com > [mailto:owner-ipng@sunroof.eng.sun.com] On Behalf Of Guru Yeleswarapu > Sent: Friday, September 20, 2002 2:32 PM > To: Joe Baptista; ipng@sunroof.eng.sun.com > Subject: RE: INTERVIEW - why would anyone want to be IPv6 complient > > > Iam also very much interested in the same. > I have just started looking into. > I have no information to pass it on right now. > > I really apprecaite if you could send me your list so far , > may be I can adding some stuff to it. > > Thanks > Guru Yeleswarapu > > > -----Original Message----- > > From: owner-ipng@sunroof.eng.sun.com > > [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Joe Baptista > > Sent: Friday, September 20, 2002 10:03 AM > > To: ipng@sunroof.eng.sun.com > > Subject: INTERVIEW - why would anyone want to be IPv6 complient > > > > > > > > Hello: > > > > I'm writing an article on why anyone (individual or business) would > > want to incorporate IPv6 services into their systems. This is a > > follow up to my earlier article at the following URL: > > > > http://www.circleid.com/articles/2533.asp > > > > If you can help please drop me a line. > > > > Also I am compiling a list of IPv6 providers - if you provide IPv6 > > services let me know. I have already requested this on nanog and > > already have a list in process. > > > > Cheers > > Joe Baptista > > > > -- > > Planet Communications & Computing Facility > > a division of The dot.GOD Registry, Limited > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home 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 Sep 23 11:14:50 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8NIEnwf000848; Mon, 23 Sep 2002 11:14:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8NIEnQQ000847; Mon, 23 Sep 2002 11:14:49 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8NIEiwf000840 for ; Mon, 23 Sep 2002 11:14:44 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8NIElMq014095 for ; Mon, 23 Sep 2002 11:14:47 -0700 (PDT) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.130]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA23158 for ; Mon, 23 Sep 2002 11:14:41 -0700 (PDT) Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.194.24]) by e32.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id g8NIBxOj061548; Mon, 23 Sep 2002 14:12:00 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.12.14]) by westrelay03.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g8NIAg6L048856; Mon, 23 Sep 2002 12:10:42 -0600 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id g8NI9fd18304; Mon, 23 Sep 2002 14:09:41 -0400 Message-Id: <200209231809.g8NI9fd18304@rotala.raleigh.ibm.com> To: Robert Elz cc: iesg@ietf.org, ipng@sunroof.eng.sun.com Subject: Re: Not Ready for Draft? draft-ietf-ipngwg-addr-arch-v3-10.txt In-Reply-To: Message from "Fri, 20 Sep 2002 18:19:39 +0700." <4582.1032520779@munnari.OZ.AU> Date: Mon, 23 Sep 2002 14:09:40 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk First, thanks for clarifying the issue you have. I apparently didin't fully understand your concern the first time around. Robert Elz writes: > What my message to the IESG requested, was that either that text be > deleted (there may be one or two other references as well - in a > message to the WG list a while ago I listed all the changes that should > be made, they're all simple deletes), or that the implementation reports > show at least 2 implementations of this requirement/feature. I still do not believe either of your requests needs to be made. Let me quote another part of the addressing architecture: IPv6 nodes may have considerable or little knowledge of the internal structure of the IPv6 address, depending on the role the node plays (for instance, host versus router). At a minimum, a node may consider that unicast addresses (including its own) have no internal structure: | 128 bits | +-----------------------------------------------------------------+ | node address | +-----------------------------------------------------------------+ That is, a host is not required to know what part of an address is an interface identifier and what is not. Thus, there is no requirement in addr-arch that implementations somehow test for the two components and verify that they satisfy particular properties. Indeed, for a node that only understands addresses, you seem to be suggesting that such an implementation would also have to reject a request to set a specific address on an interface, and instead require that addresses be entered as a (prefix, IID) pair, so that properties of (say) the IID could be verified/enforced. > Note: to implement this feature, the implementation would have to > prohibit any global unicast address (000 excepted...) from having > an interface id that was anything other than 64 bits long. Or, from > having m+n in the above diagram being any different from 64 (which, of > course, is the same thing). You seem to be saying that implementations must follow a extermely strict interpretation of a spec. Allow only that that is explcitely permitted by the text, and reject everything else, including a superset of the required feature. I.e., it's not enough to enter/check an the address, one must know what its internal components are (prefix, IID) and test both of those. There is no such requirement in the spec that I can see. And no such requirement in 2026 either. > And so, I did mean "use" not "implement", as if I can use an address > that does not have a 64 bit IID (that is, if I can make m+n > 64) then > clearly the implementation is not implementing the above feature. This goes too far, IMO. You are saying that implementations can't implement a superset of some feature in order for that feature to have been supported properly. The purpose of 2026 interoperability testing is to ensure that the words in the spec are sufficient to implement from and not result in any interoperabilty features. If someone implements a superset of feature X, and that implementation interoperates just fine with other implementations of X, that is not inherently a problem. And in the case of IIDs, it's clear from the implementation report that a number of implementations have implemented them. > All that is needed to show that the implementation does not implement > this particular feature, is to (attempt to) configure an address that > has something other than a 64 bit IID. Because there is no way to take an arbitrary address, and determine whether the IID is 64 bits or not, this is not something implementations can realistically check. > If it works, then the implementation > doesn't implement the two paragraphs I quoted, and cannot count as one > of the two that do, which is required for this feature to remain in the > doc when it advances to DS. Disagree, per above. > As for ... > | What is your evidence that *implementors* are widely ignoring these > | requirements? I am aware of none. > jade# ifconfig fxp0 > fxp0: flags=8843 mtu 1500 > media: Ethernet 10baseT > status: active > [link locals and irrelevant cruft deleted] > inet6 3ffe:b80:53:1234:2222::1 prefixlen 112 > There's one. There, right before your eyes, is a global IPv6 > address. that starts with something other than 000, and in which m+n=112 > (which is bigger than 64). That is, the IID in this global address > is 16 bits, not 64. Correction: the address has been configured with a netmask of 112 bits. How the netmask is configured is independent of what IID is used. One can assign a 112 bit mask on an IID that is in EUI-64 format (which is what was done above). That, per se, is not an indication of a problem. > What's more, it works ... Right. The WG wants it to work this way... > That is, the IESG cannot advance a specification to DS, unless the WG > chair (using the WG to assist, one would normally assume) has documented > at least 2 implementations of every feature (interoperable ones, but that > part isn't likely to be an issue here). The requirement is that folks implement EUI-64s IIDs. It is not that implementations check for and reject any address or IID that isn't guaranteed to follow the format. > And to be 100% clear, the feature / requirement that I am objecting to, > is the one that *requires* every IID to be 64 bits, and nothing else. Understood. But I disagree with the requirements you believe that implementations need to satisfy in order for addr-arch to go to Draft Standard. That bar is too high, as it basically requires that implementations check for lots and lots of things that are not explicitely allowed prevent them from being used. 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 Sep 23 15:02:57 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8NM2uwf002156; Mon, 23 Sep 2002 15:02:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8NM2ulr002155; Mon, 23 Sep 2002 15:02:56 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8NM2owf002148 for ; Mon, 23 Sep 2002 15:02:50 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8NM2sMq015028 for ; Mon, 23 Sep 2002 15:02:54 -0700 (PDT) Received: from ncsmtp02.ogw.rr.com (ncsmtp02.ogw.rr.com [24.93.67.83]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA20985 for ; Mon, 23 Sep 2002 15:02:48 -0700 (PDT) Received: from mail5.nc.rr.com (fe5 [24.93.67.52]) by ncsmtp02.ogw.rr.com (8.12.5/8.12.2) with ESMTP id g8NM3Aur005052 for ; Mon, 23 Sep 2002 18:03:10 -0400 (EDT) Received: from nc.rr.com ([24.162.252.183]) by mail5.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Mon, 23 Sep 2002 18:02:47 -0400 Message-ID: <3D8F8EEA.3277CF72@nc.rr.com> Date: Mon, 23 Sep 2002 18:00:10 -0400 From: Brian Haberman X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: IPng Mailing List Subject: MLD source address selection draft Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk All, Several people have mentioned the conflict that exists between the MLD spec (RFC 2710) and NDP (RFC 2461). NDP requires nodes to join the solicited-node multicast address in order to perform Address auto-config. However, MLD requires the source IPv6 address to be a valid link-local address. So, I have cobbled together a short draft to clarify the source address selection criteria for MLD. It only applies to 2710 (not the MLDv2 draft that already takes care of the problem). The draft is available in the draft repository at http://www.ietf.org/internet-drafts/draft-ietf-magma-mld-source-00.txt. Comments should be directed to me or the magma mailing list. 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 Sep 23 20:24:24 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8O3OOwf004334; Mon, 23 Sep 2002 20:24:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8O3OONA004333; Mon, 23 Sep 2002 20:24:24 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8O3OIwf004326 for ; Mon, 23 Sep 2002 20:24:18 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8O3ONPG008198 for ; Mon, 23 Sep 2002 20:24:23 -0700 (PDT) Received: from ALPHA1.CC.MONASH.EDU.AU (alpha1.cc.monash.edu.au [130.194.1.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA27139 for ; Mon, 23 Sep 2002 21:24:17 -0600 (MDT) Received: from kapow.its.monash.edu.au ([130.194.1.71]) by vaxc.cc.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01KMVPI5LWZ69DN3YR@vaxc.cc.monash.edu.au> for ipng@sunroof.eng.sun.com; Tue, 24 Sep 2002 13:23:58 +1000 Received: from kapow.its.monash.edu.au (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id DC51F20022; Tue, 24 Sep 2002 13:23:56 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by kapow.its.monash.edu.au (Postfix) with ESMTP id 76DC72002E; Tue, 24 Sep 2002 13:23:49 +1000 (EST) Date: Tue, 24 Sep 2002 13:23:49 +1000 From: Greg Daley Subject: Re: MLD source address selection draft To: Brian Haberman , ipng@sunroof.eng.sun.com Reply-to: greg.daley@eng.monash.edu.au Message-id: <3D8FDAC5.4040706@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 References: <3D8F8EEA.3277CF72@nc.rr.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Brian, That's short and sweet. Thanks for the clarification. Greg Daley Brian Haberman wrote: > All, > Several people have mentioned the conflict that exists between > the MLD spec (RFC 2710) and NDP (RFC 2461). NDP requires nodes to > join the solicited-node multicast address in order to perform Address > auto-config. However, MLD requires the source IPv6 address to be a > valid link-local address. So, I have cobbled together a short draft > to clarify the source address selection criteria for MLD. It only > applies to 2710 (not the MLDv2 draft that already takes care of the > problem). The draft is available in the draft repository at > http://www.ietf.org/internet-drafts/draft-ietf-magma-mld-source-00.txt. > > Comments should be directed to me or the magma mailing list. > > 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 Sep 24 03:03:15 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8OA3Fwf005068; Tue, 24 Sep 2002 03:03:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8OA3FDD005067; Tue, 24 Sep 2002 03:03:15 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8OA39wf005060 for ; Tue, 24 Sep 2002 03:03:10 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8OA3CPG019715 for ; Tue, 24 Sep 2002 03:03:13 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.97.9]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA13611 for ; Tue, 24 Sep 2002 03:02:05 -0700 (PDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g8OA0F328014; Tue, 24 Sep 2002 17:00:23 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g8O9xN724564; Tue, 24 Sep 2002 16:59:23 +0700 (ICT) From: Robert Elz To: Thomas Narten cc: iesg@ietf.org, ipng@sunroof.eng.sun.com Subject: Re: Not Ready for Draft? draft-ietf-ipngwg-addr-arch-v3-10.txt In-Reply-To: <200209231809.g8NI9fd18304@rotala.raleigh.ibm.com> References: <200209231809.g8NI9fd18304@rotala.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 24 Sep 2002 16:59:23 +0700 Message-ID: <24562.1032861563@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 23 Sep 2002 14:09:40 -0400 From: Thomas Narten Message-ID: <200209231809.g8NI9fd18304@rotala.raleigh.ibm.com> | Let me quote another part of the addressing architecture: | That is, a host is not required to know what part of an address is an | interface identifier and what is not. That's fine. Now we have two things in the doc, and hosts can do one or the other. The "must be two interoperable implementations of every feature" requirement in 2026 says that if everyone happens to choose one of those, then the other has to be deleted from the spec before it goes to DS. The other choice can reappear in a new PS spec, but it cannot remain in the DS spec. Thomas, there's nothing at all unclear about this in 2026... | Thus, there is no requirement in | addr-arch that implementations somehow test for the two components and | verify that they satisfy particular properties. No, and I am not complaining about any implementation that doesn't do that. In fact, I would complain (to the authors of such a thing) if they did attempt to do that - I certainly wouldn't use such an implementation. But that's not what is important here. What matters is whether or not there are two implementations (at least) of every feature of the spec. Not whether any (or every) particular implementation conforms to the spec. | Indeed, for a node | that only understands addresses, you seem to be suggesting that such | an implementation would also have to reject a request to set a | specific address on an interface, and instead require that addresses | be entered as a (prefix, IID) pair, so that properties of (say) the | IID could be verified/enforced. No, I would hate such a thing. What I am saying, is that according to the address architecture doc, that is what is required, if hosts are to implement that feature (whether or not they are required to implement it is irrelevant here - 2026 applies to optional features just as much as to mandatory ones). If no-one is bothering to implement it, then it should be removed, correct? If anyone is bothering to implement it, then that should be documented, right? | You seem to be saying that implementations must follow a extermely | strict interpretation of a spec. Allow only that that is explcitely | permitted by the text, and reject everything else, including a | superset of the required feature. No, nothing like that at all. But consider a spec which says Saucepans MUST NOT boil potatoes. If some saucepan comes along and says, "I boil potatoes, I'm not violating the spec, I'm just implementing a superset, because no-one is actually required to boil potatoes using this implement", you'd laugh at them. A superset cannot be such as to deliberately violate a condition of the spec, it has to implement everything required, and then can implement more. The requirement here is "m+n==64" - always (with only non-unicast, non-global, and the 000 case as exceptions). That is, a host must implement that, if it is to implement that particular feature. If you like, what the spec is saying, is Addresses MUST NOT have a IID that is any length other than 64. And you seem to be saying, OK, as long as it is possible to have an IID that is 64 bits long, that requirement is satisfied. Really? Please don't mane me give a lesson in boolean algebra and De Morgan's laws relating to the inverses of "All X" and such. If you don't believe that is what the spec is saying, then at the very least it is unclear, as that's certainly how I read it. It is also an interpretation I have seen quoted by (several) other people in various other contexts. So, if it is (commonly) being read as saying something different than what it is actually supposed to mean, surely it should be corrected so it is clear. By all means propose wording to make this happen. If your wording for this is in accord with what you seem to be saying here, and the WG accepts it, then I doubt I will have any problems. That is, if your replacement wording makes it clear that it is OK for implementations to allow IIDs that are shorter (or in fact, longer) than 64 bits if they desire, and that m+n is not actually required to be 64 after all. | I.e., it's not enough to enter/check | an the address, one must know what its internal components are | (prefix, IID) and test both of those. If the host is implementing that feature, then yes. But note that we're not discussing the adequacy of host implementations here, we're discussing the correct procedures for advancing the spec. That means that it is irrelevant whether or not the feature in question is supposedly mandatory to implement or not, all that matters is that it is in the doc, and there aren't any documented implementations of it. Hence, it has to go (or documentation of implementations must be provided). | This goes too far, IMO. You are saying that implementations can't | implement a superset of some feature in order for that feature to have | been supported properly. Once again, this is not a superset, it is a direct violation of the wording. And once again, I am not complaining about any implementation. The complaint is about the spec, and its ability to go unchanged to DS. | The purpose of 2026 interoperability testing | is to ensure that the words in the spec are sufficient to implement | from and not result in any interoperabilty features. Once again, that is only a part of it. It is also to get rid of features that no-one is bothering to implement. That's why it says that every feature must be documented. It isn't good enough to simply say "these two implementations interoperate with each other". | If someone implements a superset of feature X, Supersets are irrelevant here. No-one has implemented a superset of the feature in question. Remember, that what I'm asking to be deleted, or for which interop reports need to be generated, is the "all IIDs are required to be 64 bits long" language. The text in the spec (that is of concern) is not "all implementations are required to support 64 bit IIDs" - if it were, then yes, supporting 64 would be enough, and if 70, 80, ... bit IIDs supported, that would be a superset. But that's not what it says, it says, very clearly, and in two different ways in two different sections, "*ALL* IIDs are *required* to be 64 bits" (referring to global unicast addresses that don't start with the first three bits being 000). I am still waiting for you (or someone) to point to a single implementation of this feature. Once we get one, we could start looking for two... | And in the case of IIDs, it's clear from the | implementation report that a number of implementations have | implemented them. Of course. No-one is suggesting that IIDs be deleted from the spec. Nor EUI-64 for that matter. All I am asking is for the language that mandates that IIDs be 64 bits long, and that no other length is permitted, be removed (or the implementations of it be documented). Are you somehow managing to miss that particular text in the draft? | Because there is no way to take an arbitrary address, and determine | whether the IID is 64 bits or not, this is not something | implementations can realistically check. If this were true, and there was no way for an implementation to tell whether a prefix is 64 bits long or not, then what would be the point of including language in the architecture doc to mandate it. That would make the requirement mere fluff. But of course, that is utter nonsense. For any local address, the implementation must know which part identifies the net (link) and which part identifies nodes on the net (link). Otherwise it has no way to tell which other nodes are "on link" and which are not. And even if this is necessary only for a subset of links, it clearly is possible. Of course, in practice, nodes are always told what the prefix length is, for any address configured (not that they would need to be if the addr arch spec was followed literally, as it would always be a constant 64). | > inet6 3ffe:b80:53:1234:2222::1 prefixlen 112 | Correction: the address has been configured with a netmask of 112 | bits. Which parts of "prefixlen" do you not understand? IPv6 doesn't have netmasks... | How the netmask is configured is independent of what IID is | used. Now this is an interesting argument, and truly clutching at straws I believe. Consider the wording from section 2.1 (Addressing Model) of the draft ... Currently IPv6 continues the IPv4 model that a subnet prefix is associated with one link. Multiple subnet prefixes may be assigned to the same link. Also see section 2.5.1, where Interface Identifiers are defined... Interface identifiers in IPv6 unicast addresses are used to identify interfaces on a link. So, we have the subnet prefix, which identifies the link, and the IID that identifies the nodes on the link, and the prefixlen which tells the implementation where the boundary between the two is. Then we have language in the doc which says that the IID must be 64 bits, and other language that says that the combined global routing prefix, and subnet ID (which together make the subnet prefix) must be 64 bits long. How can the prefix length (or subnet mask if you insist on calling it that) be anything other than 64, and actually be complying with the requirement in the spec that m+n==64, or the one about the IID being 64 bits wide? But if that's your interpretation of what the spec is actually saying is required, then we certainly need different text to explain it, as no-one else I know of has ever claimed that as a legitimate interpretation before. Rather, the addr arch doc is commonly quoted by people who claim (and correctly as it is written, I believe - which is why it needs to be changed) that it specifies that the prefixlen of any link is required to be 64, and nothing else is permitted. So, if that's not what it is actually saying, then the text clearly needs corrections so it is understood the way you're claiming that it should be understood. | One can assign a 112 bit mask on an IID that is in EUI-64 format | (which is what was done above). Um, no, that's not what was done above. EUI-64 format also makes statements about the 'u' bit, and if you look, you'll see that the address that was configured has the 'u' bit set, but most certainly wasn't formed from any kind of global identifier. And note this was an ethernet (that's what fxp0 is on NetBSD) which means that its tokens would be 48 bit MAC addresses, so a correctly formed (global) EUI-64 would have had the FFFE value in the middle of it. That's missing too. | That, per se, is not an indication of a problem. It looks like one of three cases is true here. The spec really means something quite different from the way everyone interprets it, in which case it should be corrected. The spec doesn't really mean anything at all, in which case it should be deleted. The spec means exactly what it says, in which case either 2 implementations of it need to be documented, or the spec has to be deleted (from this doc for it to go to DS status). You can pick one of those, but I can't see any other choices. In each of the above "the spec" means the particular lines from the draft in question that I quoted in my last message. | > What's more, it works ... | Right. The WG wants it to work this way... In that case, why is the addr arch doc not actually saying what the WG wants? On the other hand, if what you are saying here is that the WG wants to have this in the spec, and to have the spec advanced to DS, even though there aren't 2 implementations of this feature, then I'm afraid it is the IESG's job to say "no". 2026 leaves it no choice. It isn't as if the IESG is usually shy about rejecting drafts that WG's have agreed to, or ignoring specific "wants" from working groups. And that's when there isn't even a specific requirement that requires the IESG reject the request, which there is here. | The requirement is that folks implement EUI-64s IIDs. That is *a* requirement. That's not the one I am concerned about. Hasn't that much become clear yet? There is also this other requirement that every (global unicast, 000 case excepted) address have m+n == 64. In that m is the number of bits in the global routing prefix, and n is the number of bits in the subnet ID. Is it possible that you can't see that in the draft? The language isn't obtuse - it isn't required that anyone read this requirement out of a combination of other statements, or anything complex like that, after all, what it says is ... All global unicast addresses other than those that start with binary 000 have a 64-bit interface ID field (i.e., n + m = 64), formatted as described in section 2.5.1. Notice that "All [...] addresses". It leaves no room for there to be a single address (other than the explicit exceptions) which isn't formatted like this. Look at the diagram above it (this is section 2.5.4). That shows what m and n mean. Look at the definition of Interface ID, to see what that means. And you can just believe me that in the implementation I showed (the one you claimed earlier didn't exist, though I think it is what everyone does), when an address has a prefixlen of 112, it means that m+n == 112. The implementation doesn't actually care how much of that is m, and how much is n, that is someone else's business - nor does the addr arch doc care, all it currently requires is that m+n==64: m=63 n=1, or m=64 n=0, or m=3 n=61 would all satisfy it, but m+n==112 does not. That one is the one in question. And once more, I am not complaining about this implementation, I like it a lot, it does exactly what I think it should do. But it isn't one of the ones which could possibly be used to claim that the feature in question is implemented (and nor are any others I have seen - but of course, that isn't all that exist, so it is possible that there are the needed 2 implementations somewhere, just not documented). | It is not that | implementations check for and reject any address or IID that isn't | guaranteed to follow the format. If nothing is supposed to check/reject addresses of IIDs that aren't 64 bits long, why is the text in the doc? If it is just that implementations are allowed to reject that, then that's an optional feature right? And 2026 requires that there be at least two implementations of each optional feature, or the feature must be removed. | > And to be 100% clear, the feature / requirement that I am objecting to, | > is the one that *requires* every IID to be 64 bits, and nothing else. | | Understood. It doesn't seem to be, because you keep referring to implementations implementing IIDs, which has nothing to do with this at all. The "nothing else" above was meant to refer to "nothing other than 64 bits", not that I am objecting to no other parts of the spec (because there's also the 'u' bit of course, that is pending the outcome of this discussion). | But I disagree with the requirements you believe that | implementations need to satisfy in order for addr-arch to go to Draft | Standard. 2026 really is quite clear. | That bar is too high, as it basically requires that | implementations check for lots and lots of things that are not | explicitely allowed prevent them from being used. No, that would not be the case at all, we're not talking about undocumented cases here, or things just left open and undefined, or unspecified. Let's look at another couple of cases for a minute, which aren't in this area of dispute, so might make things just a bit clearer. 2.5.3 The Loopback Address [...] The loopback address must not be used as the source address in IPv6 packets that are sent outside of a single node. Now, if an implementation was sending packets with 0::1 as the source address, it clearly wouldn't be complying with the spec, right? That wouldn't just be a "superset" implementation, would it? So, for link locals to pass into the DS draft, we need at least two implementations that don't send ::1 as a source address. I doubt that is any kind of problem. Note, it is not important if there are buggy implementations as well, which do use ::1 as a source addr, unless they're caused by a lack of clarity in the spec (which would not be likely here), but there must be at least two implementations which do implement the spec. Agreed? On the other hand: 2.5.5 IPv6 Addresses with Embedded IPv4 Addresses [...] | 80 bits | 16 | 32 bits | +--------------------------------------+--------------------------+ |0000..............................0000|0000| IPv4 address | +--------------------------------------+----+---------------------+ Note: The IPv4 address used in the "IPv4-compatible IPv6 address" must be a globally-unique IPv4 unicast address. [...] | 80 bits | 16 | 32 bits | +--------------------------------------+--------------------------+ |0000..............................0000|FFFF| IPv4 address | +--------------------------------------+----+---------------------+ In that section, nothing at all is said about (IPv6) addresses which start with or 0::FFFF:0:0/96 but which don't contain an IPv4 address in the low 32 bits. Nor is anything said about addresses that start with 0::/80 but which don't have 0000 or FFFF in the next 16 bits. Implementations which supported any of that would be supersets of the spec. Clearly there is no requirement in the spec for such things to be rejected. But when an IPv4 address is used in a 0::/96 address, then it is required to be a globally unique one. If no-one implements that, then that requirement would have to be deleted (but I believe that actually is tested for in at least some implementations). So, here, as long as there are two implementations of this, with or without optional extensions, this part is also just fine to advance to DS. This needs to be done for every feature in every spec that the IESG considers advancing to DS. Note I'm not about to require that the IESG do all this all by itself, we have the rest of the IETF community along to help. First, the WG is supposed to document it all in the implementation report. And then, we have the rest of the community (like me in this case) who should be examining all of this, and making known any problems that we can see. But once the IESG are made aware of a feature in a spec, for which there aren't two documented implementations, it has no choice, according to 2026, other than to request the missing documentation, or reject the doc's advancement to DS, or to require that the unimplemented features be removed from the doc, after which what is left can advance to DS. 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 Sep 24 04:56:06 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8OBu6wf005663; Tue, 24 Sep 2002 04:56:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8OBu5fq005662; Tue, 24 Sep 2002 04:56:05 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8OBtxwf005655 for ; Tue, 24 Sep 2002 04:55:59 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8OBu3Mq003992 for ; Tue, 24 Sep 2002 04:56:03 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA11952 for ; Tue, 24 Sep 2002 04:55:57 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23487; Tue, 24 Sep 2002 07:54:06 -0400 (EDT) Message-Id: <200209241154.HAA23487@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-ipv6-ipaddressassign-04.txt Date: Tue, 24 Sep 2002 07:54:06 -0400 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 IP Version 6 Working Group Working Group of the IETF. Title : A Flexible Method for Managing the Assignment of Bites of an IPv6 Address Block Author(s) : M. Blanchet Filename : draft-ietf-ipv6-ipaddressassign-04.txt Pages : 9 Date : 2002-9-23 This document proposes a method to manage the assignment of bits of an IPv6 address block or range. When an organisation needs to make an address plan for its subnets or when an ISP needs to make an address plan for its customers, this method enables the organisation to postpone the final decision on the number of bits to partition in the address space they have. It does it by keeping the bits around the borders of the partition to be free as long as possible. This scheme is applicable to any bits addressing scheme using bits with partitions in the space, but its first intended use is for IPv6. It is a generalization of RFC1219 and can be used for IPv6 assignments. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-ipaddressassign-04.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-ipv6-ipaddressassign-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipv6-ipaddressassign-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-9-23152117.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-ipaddressassign-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-ipaddressassign-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-9-23152117.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 Wed Sep 25 00:36:20 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8P7aJwf013058; Wed, 25 Sep 2002 00:36:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8P7aJMZ013057; Wed, 25 Sep 2002 00:36:19 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8P7aEwf013050 for ; Wed, 25 Sep 2002 00:36:14 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8P7aHPG024572 for ; Wed, 25 Sep 2002 00:36:17 -0700 (PDT) Received: from dot-god.com (d150-250-196.home.cgocable.net [24.150.250.196]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA24913 for ; Wed, 25 Sep 2002 01:36:11 -0600 (MDT) Received: from localhost (baptista@localhost) by dot-god.com (8.11.4/8.11.4) with ESMTP id g8P7aOC12902; Wed, 25 Sep 2002 03:36:24 -0400 Date: Wed, 25 Sep 2002 03:36:23 -0400 (EDT) From: Joe Baptista To: Guru Yeleswarapu cc: Subject: RE: INTERVIEW - why would anyone want to be IPv6 complient In-Reply-To: <000001c260ed$31de40c0$5e41100a@pcir000997.sj.broadcom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi: Here it is. I would love to follow up and interview you some time. http://www.circleid.com/articles/2539.asp Cheers Joe Baptista -- Planet Communications & Computing Facility a division of The dot.GOD Registry, Limited On Fri, 20 Sep 2002, Guru Yeleswarapu wrote: > Iam also very much interested in the same. > I have just started looking into. > I have no information to pass it on right now. > > I really apprecaite if you could send me your list so far , may be > I can adding some stuff to it. > > Thanks > Guru Yeleswarapu > > > -----Original Message----- > > From: owner-ipng@sunroof.eng.sun.com > > [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Joe Baptista > > Sent: Friday, September 20, 2002 10:03 AM > > To: ipng@sunroof.eng.sun.com > > Subject: INTERVIEW - why would anyone want to be IPv6 complient > > > > > > > > Hello: > > > > I'm writing an article on why anyone (individual or business) would want > > to incorporate IPv6 services into their systems. This is a follow up to > > my earlier article at the following URL: > > > > http://www.circleid.com/articles/2533.asp > > > > If you can help please drop me a line. > > > > Also I am compiling a list of IPv6 providers - if you provide IPv6 > > services let me know. I have already requested this on nanog and already > > have a list in process. > > > > Cheers > > Joe Baptista > > > > -- > > Planet Communications & Computing Facility > > a division of The dot.GOD Registry, Limited > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home 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 Sep 25 00:50:11 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8P7oBwf013123; Wed, 25 Sep 2002 00:50:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8P7oBn5013122; Wed, 25 Sep 2002 00:50:11 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8P7o6wf013115 for ; Wed, 25 Sep 2002 00:50:06 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8P7o9PG000945 for ; Wed, 25 Sep 2002 00:50:09 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA05840 for ; Wed, 25 Sep 2002 00:50:03 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g8P7o0V07082 for ; Wed, 25 Sep 2002 10:50:01 +0300 Date: Wed, 25 Sep 2002 10:50:00 +0300 (EEST) From: Pekka Savola To: ipng@sunroof.eng.sun.com Subject: draft on v6 firewalling (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This could be of interest. Comments directly to me or possibly on the v6ops mailing-list, I think. There may be some issues wrt. RFC2460 that may warrant discussion here too, though. -- 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: Wed, 25 Sep 2002 10:47:41 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Subject: draft on v6 firewalling Hello, I've submitted an I-D on IPv6 firewalling issues, and it should be available in the repository shortly. In the meantime, it's available at: http://www.netcore.fi/pekkas/ietf/draft-savola-v6ops-firewalling-00.txt Below is the abstract: There are quite a few potential problems regarding firewalling or packet filtering in IPv6 environment. These include slight ambiguity in the IPv6 specification, problems parsing packets beyond unknown Extension Headers and Destination Options, and introduction of end- to-end encrypted traffic and peer-to-peer applications. There may also be need to extend packet matching to include some Extension Header or Destination Option fields. This draft discusses these issues to raise awareness and proposes some tentative solutions or workarounds. It's 8 pages. Thanks. -- 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 Sep 25 00:52:09 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8P7q9wf013140; Wed, 25 Sep 2002 00:52:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8P7q8KZ013139; Wed, 25 Sep 2002 00:52:08 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8P7q3wf013132 for ; Wed, 25 Sep 2002 00:52:03 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8P7q5PG001372 for ; Wed, 25 Sep 2002 00:52:06 -0700 (PDT) Received: from dot-god.com (d150-250-196.home.cgocable.net [24.150.250.196]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA19075 for ; Wed, 25 Sep 2002 01:52:00 -0600 (MDT) Received: from localhost (baptista@localhost) by dot-god.com (8.11.4/8.11.4) with ESMTP id g8P7qES16765; Wed, 25 Sep 2002 03:52:14 -0400 Date: Wed, 25 Sep 2002 03:52:13 -0400 (EDT) From: Joe Baptista To: Guru Yeleswarapu cc: Subject: RE: INTERVIEW - why would anyone want to be IPv6 complient 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 sorry about that - i didn't mean to cc the list. Cheers Joe Baptista -- Planet Communications & Computing Facility a division of The dot.GOD Registry, Limited On Wed, 25 Sep 2002, Joe Baptista wrote: > Hi: > > Here it is. I would love to follow up and interview you some time. > > http://www.circleid.com/articles/2539.asp > > > Cheers > Joe Baptista > > -- > Planet Communications & Computing Facility > a division of The dot.GOD Registry, Limited > > On Fri, 20 Sep 2002, Guru Yeleswarapu wrote: > > > Iam also very much interested in the same. > > I have just started looking into. > > I have no information to pass it on right now. > > > > I really apprecaite if you could send me your list so far , may be > > I can adding some stuff to it. > > > > Thanks > > Guru Yeleswarapu > > > > > -----Original Message----- > > > From: owner-ipng@sunroof.eng.sun.com > > > [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Joe Baptista > > > Sent: Friday, September 20, 2002 10:03 AM > > > To: ipng@sunroof.eng.sun.com > > > Subject: INTERVIEW - why would anyone want to be IPv6 complient > > > > > > > > > > > > Hello: > > > > > > I'm writing an article on why anyone (individual or business) would want > > > to incorporate IPv6 services into their systems. This is a follow up to > > > my earlier article at the following URL: > > > > > > http://www.circleid.com/articles/2533.asp > > > > > > If you can help please drop me a line. > > > > > > Also I am compiling a list of IPv6 providers - if you provide IPv6 > > > services let me know. I have already requested this on nanog and already > > > have a list in process. > > > > > > Cheers > > > Joe Baptista > > > > > > -- > > > Planet Communications & Computing Facility > > > a division of The dot.GOD Registry, Limited > > > > > > -------------------------------------------------------------------- > > > IETF IPng Working Group Mailing List > > > IPng Home 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 Wed Sep 25 04:40:49 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8PBenwf014100; Wed, 25 Sep 2002 04:40:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8PBenxZ014099; Wed, 25 Sep 2002 04:40:49 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8PBehwf014092 for ; Wed, 25 Sep 2002 04:40:43 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8PBelPG024020 for ; Wed, 25 Sep 2002 04:40:47 -0700 (PDT) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA28388 for ; Wed, 25 Sep 2002 04:40:41 -0700 (PDT) From: john.loughney@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g8PBe8T00884 for ; Wed, 25 Sep 2002 14:40:08 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 25 Sep 2002 14:38:45 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 25 Sep 2002 14:38:38 +0300 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: Node requirements next steps X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Wed, 25 Sep 2002 14:34:26 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38F3E@esebe004.ntc.nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Not Ready for Draft? draft-ietf-ipngwg-addr-arch-v3-10.txt Thread-Index: AcJjsiqbV32NL7N1RByU0TYva5L3rwA0uHIQ To: X-OriginalArrivalTime: 25 Sep 2002 11:38:38.0785 (UTC) FILETIME=[173ABB10:01C26488] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g8PBeiwf014093 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear all, I'd like to get some progress on the node requirements draft. I have some outstanding issues to address, which I will in the next few days. However, the high-order bit to settle is about the requirements language. The current draft can be found here: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-node-requirements-01.txt The design team decided to use the following terms, in concert with the keywords from 2026. Unconditionally Mandatory If a node claims compliance to this document, then it must support the behavior specified within each conformance group listed of type unconditionally mandatory. Conditionally Mandatory Conditionally mandatory groups include those which are mandatory only if a particular condition is true, such as whether a specific type of hardware is present, or whether another given group is implemented. When a conditionally mandatory specification or group is described, the condition will also be described. A given RFC or portion thereof can sometimes appear in multiple conformance groups, with different conditions. Unconditionally Optional Behavior that is neither unconditionally mandatory nor conditionally mandatory is unconditionally optional for compliance to this document. The reason we felt this type of language was used becase: 1) It was felt that IPv6 nodes may be have very different applicability, therefore some functionality are mandatory in some circumstances, but not in all. 2) 2026 is not a mandatory reference, and in many cases, some of the normative references in this draft do not use the 2026 language. 3) MUST, SHOULD, MAY, etc. do not cover cases where there is dependency on other functions. For example, support for IPv6 over Ethernet is not a MAY, SHOULD or MUST. One can imagine that in the case of a wired server running IPv6, IPv6 over Ethernet would be a should, but in the case of a purely wireless device IPv6 over Ethernet is useless. If you have an opinion on this, please speak up. thanks, 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 Wed Sep 25 04:59:48 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8PBxmwf014210; Wed, 25 Sep 2002 04:59:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8PBxmsk014209; Wed, 25 Sep 2002 04:59:48 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8PBxewf014202 for ; Wed, 25 Sep 2002 04:59:40 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8PBxiMq005437 for ; Wed, 25 Sep 2002 04:59:44 -0700 (PDT) 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 FAA23840 for ; Wed, 25 Sep 2002 05:59:38 -0600 (MDT) Received: from localhost ([3ffe:501:100f:1048:ed77:4f38:46af:7528]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g8PBxZt95648; Wed, 25 Sep 2002 20:59:35 +0900 (JST) Date: Wed, 25 Sep 2002 21:00:06 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Michael Hunter Cc: ipng@sunroof.eng.sun.com Subject: Re: two 2292bis errors In-Reply-To: <20020922173432.216be897.michael.hunter@eng.sun.com> References: <20020922173432.216be897.michael.hunter@eng.sun.com> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 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 20000228(IM140) Lines: 19 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Sun, 22 Sep 2002 17:34:32 -0700, >>>>> Michael Hunter said: > In 2292bis (rev 7) there are two errors: > 1) ND_OPT_PI_FLAG_ROUTER only shows up in section 15 (summary of new > definitions). > 2) ip6_ext shows up in section 15 (summary of new definitions) but it > is mentioned in the change log as having been removed. There is no > text describing it. You're right, thanks for the correction. I'll fix them in the next revision of the draft (which will be issued in response to comments from Thomas). 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 Sep 25 06:00:40 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8PD0ewf014586; Wed, 25 Sep 2002 06:00:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8PD0dfn014585; Wed, 25 Sep 2002 06:00:40 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8PD0Wwf014578 for ; Wed, 25 Sep 2002 06:00:32 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8PD0aPG012718 for ; Wed, 25 Sep 2002 06:00:36 -0700 (PDT) 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 HAA23545 for ; Wed, 25 Sep 2002 07:00:30 -0600 (MDT) Received: from localhost ([3ffe:501:100f:1048:ed77:4f38:46af:7528]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g8PD0Qt95946; Wed, 25 Sep 2002 22:00:26 +0900 (JST) Date: Wed, 25 Sep 2002 22:00:56 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Michael Hunter Cc: ipng@sunroof.eng.sun.com Subject: Re: 2292bis ip6_rthdr0 flexible array member In-Reply-To: <20020923130121.4bdf9280.michael.hunter@eng.sun.com> References: <20020911152942.42f48e0d.michael.hunter@eng.sun.com> <20020923130121.4bdf9280.michael.hunter@eng.sun.com> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 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 20000228(IM140) Lines: 78 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Mon, 23 Sep 2002 13:01:21 -0700, >>>>> Michael Hunter said: >> Sorry, but I don't think we should incorporate this to the >> specification. If an application writer assumes the existence of >> ip6r0_addr, the source code will not compile with a compiler that >> does not support the flexible array member. However, I don't want to >> see conditional compilation tricks like this: >> >> struct ip6_rthdr0 *r; >> struct in6_addr *in6; >> >> #if __STDC_VERSION__ >= 199901L >> in6 = &r->ip6r0_addr[0]; >> #else >> in6 = (struct in6_addr *)(r + 1); >> #endif > I don't like conditional compilation either. Its a maintenance > headache. That said I think if you don't choose a easy way to access > the variable length array of addresses you will end up with > implementers choosing their own direction thus leading to conditional > compilation anyways. I don't think just choosing implementors' own direction leads to conditional compilation, but perhaps the difference of these views is not main point in this discussion. (So let's go ahead) > 1) Leave it as you currently do (KAME does this). I suspect everybody > will choose their own way to make this usable. If you are lucky there > are not so many implementations that this isn't a problem. Presonally > I prefer conditional compilation based on the c standard rev over that > based on the OS/stack flavor. > 2) Use a pre c99 length 1 array (2292, Solaris, and USAGI do this). > Realistically this is most likely to be implemented uniformly. Its in > 2292 so you should need strong reason to change it. It is a little bit > gross, but I don't think this is strong enough reason to break existing > applications. > 3) Use a FAM. Use a 2+ year old c standard to specify an emerging > API. Philosphically this seems like the cleanest thing to do. > 4) Use a combination of 2 & 3. People can then use sizeof() as a way > to determine how to allocate. This is probably too complex to be used > correctly by the masses and has the maintenace headaches of conditional > compilation. > I hope you will consider 2 or 3. I didn't remember the reason why the member name was removed, so I found it from the web. You'll get the answer from the discussion starting at the following URL: http://www.wcug.wwu.edu/lists/ipng/199908/msg00128.html According to the discussion, there seemed to be a clear consensus on the removal (though this may not be regarded as a "strong reason"). Another thought: most user applications are expected to use inet6_rth_xxx functions, instead of directly getting access to the address part following the rthdr[0] structure. Thus, either 1 nor 2 affects the typical user applications. In some limited usage, such as in kernel source, developers may want to choose their own way for their convenience like ip6r0_addr[0]. However, we do not expect portability in such limited environments, and I don't care about the possible differences as long as it is hidden from user applications. Having thought all of this, I still prefer the current 2292bis definition. (I personally could live with (2), but I prefer (1) over (2) because we had a clear consensus on this.) Can we agree on this, or do we need more discussion? 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 Sep 25 06:30:18 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8PDUHwf014873; Wed, 25 Sep 2002 06:30:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8PDTmWt014872; Wed, 25 Sep 2002 06:29:48 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8PDTgwf014865 for ; Wed, 25 Sep 2002 06:29:42 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8PDTlMq002662 for ; Wed, 25 Sep 2002 06:29:47 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA14888 for ; Wed, 25 Sep 2002 07:29:41 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g8PDTdh10007 for ; Wed, 25 Sep 2002 16:29:40 +0300 Date: Wed, 25 Sep 2002 16:29:39 +0300 (EEST) From: Pekka Savola To: ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-ietf-ipngwg-rfc2553bis-07.txt In-Reply-To: <200209201152.HAA19100@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 Fri, 20 Sep 2002 Internet-Drafts@ietf.org wrote: > Title : Basic Socket Interface Extensions for IPv6 [...] This is probably a dumb question, but is there must be a reason why these API's don't talk at all about ioctl's etc? For example, I see no standard way of obtaining (all or some) of one's IPv6 addresses, or whatever else was useful with SIOC*. -- 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 Sep 25 08:03:37 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8PF3awf015368; Wed, 25 Sep 2002 08:03:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8PF3aHU015367; Wed, 25 Sep 2002 08:03:36 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8PF3Uwf015357 for ; Wed, 25 Sep 2002 08:03:30 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8PF3YMq002628 for ; Wed, 25 Sep 2002 08:03:34 -0700 (PDT) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA27258 for ; Wed, 25 Sep 2002 08:03:29 -0700 (PDT) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 9BC855888; Wed, 25 Sep 2002 11:03:28 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 25 Sep 2002 11:03:28 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: I-D ACTION:draft-ietf-ipngwg-rfc2553bis-07.txt Date: Wed, 25 Sep 2002 11:03:28 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE938A@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-ietf-ipngwg-rfc2553bis-07.txt Thread-Index: AcJkmDjxcPOLOBEjSXSOuQraCmFEAQADFf/w From: "Bound, Jim" To: "Pekka Savola" , X-OriginalArrivalTime: 25 Sep 2002 15:03:28.0537 (UTC) FILETIME=[B47E1090:01C264A4] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g8PF3Uwf015358 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka, IOCTLs are not portable across many operating system API infrastructures. the sockets are and those apis. thats the reason. that being said check out the appendix of the suggested macros that should exist. /jim > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi] > Sent: Wednesday, September 25, 2002 9:30 AM > To: ipng@sunroof.eng.sun.com > Subject: Re: I-D ACTION:draft-ietf-ipngwg-rfc2553bis-07.txt > > > On Fri, 20 Sep 2002 Internet-Drafts@ietf.org wrote: > > Title : Basic Socket Interface Extensions for IPv6 > [...] > > This is probably a dumb question, but is there must be a > reason why these > API's don't talk at all about ioctl's etc? For example, I > see no standard > way of obtaining (all or some) of one's IPv6 addresses, or > whatever else > was useful with SIOC*. > > -- > 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 Sep 25 13:53:00 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8PKr0wf018213; Wed, 25 Sep 2002 13:53:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8PKr0p9018212; Wed, 25 Sep 2002 13:53:00 -0700 (PDT) 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.17.55]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8PKqrwf018205 for ; Wed, 25 Sep 2002 13:52:54 -0700 (PDT) Received: from laphroig (laphroig.Eng.Sun.COM [129.146.85.171]) by jurassic.eng.sun.com (8.12.6+Sun/8.12.6) with SMTP id g8PKqwdZ786410; Wed, 25 Sep 2002 13:52:58 -0700 (PDT) Date: Wed, 25 Sep 2002 13:52:58 -0700 From: Michael Hunter To: jinmei@isl.rdc.toshiba.co.jp Cc: ipng@sunroof.eng.sun.com Subject: Re: 2292bis ip6_rthdr0 flexible array member Message-Id: <20020925135258.3861fa68.michael.hunter@eng.sun.com> In-Reply-To: References: <20020911152942.42f48e0d.michael.hunter@eng.sun.com> <20020923130121.4bdf9280.michael.hunter@eng.sun.com> X-Mailer: Sylpheed version 0.7.6 (GTK+ 1.2.10; sparc-sun-solaris2.10) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 25 Sep 2002 22:00:56 +0900 JINMEI Tatuya / $B?@L@C#:H(B wrote: [...] > I didn't remember the reason why the member name was removed, so I > found it from the web. You'll get the answer from the discussion > starting at the following URL: > > http://www.wcug.wwu.edu/lists/ipng/199908/msg00128.html > > According to the discussion, there seemed to be a clear consensus on > the removal (though this may not be regarded as a "strong reason"). poster + 1 FAM preferred (removal next) 1 removal 1 its nice to have the array member 1 but I don't need the array member I'm not sure what the overall membership of the interested parties was but that doesn't sound like a large sample. [...] > Another thought: most user applications are expected to use > inet6_rth_xxx functions, instead of directly getting access to the > address part following the rthdr[0] structure. Thus, either 1 nor 2 > affects the typical user applications. So why create incompatibilities with 2292 if you expect the feature being broken to be used less in the future? Whats the gain? [...] > Having thought all of this, I still prefer the current 2292bis > definition. (I personally could live with (2), but I prefer (1) over > (2) because we had a clear consensus on this.) > > Can we agree on this, or do we need more discussion? I'm not buying the reasons I've seen so far for this incompatibility with 2292. I believe you need a reason other then "its ugly" to break users code. mph -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 25 14:33:39 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8PLXdwf018402; Wed, 25 Sep 2002 14:33:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8PLXdlE018401; Wed, 25 Sep 2002 14:33:39 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8PLXXwf018394 for ; Wed, 25 Sep 2002 14:33:33 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8PLXaPG000160 for ; Wed, 25 Sep 2002 14:33:36 -0700 (PDT) Received: from zcamail04.zca.compaq.com (zcamail04.zca.compaq.com [161.114.32.104]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA18373 for ; Wed, 25 Sep 2002 14:33:31 -0700 (PDT) Received: from taynzmail03.nz-tay.cpqcorp.net (taynzmail03.nz-tay.cpqcorp.net [16.47.4.103]) by zcamail04.zca.compaq.com (Postfix) with ESMTP id 5A689117B; Wed, 25 Sep 2002 14:33:31 -0700 (PDT) Received: from hp.com (whitestar.zk3.dec.com [16.140.64.49]) by taynzmail03.nz-tay.cpqcorp.net (Postfix) with ESMTP id 77AB9E4E; Wed, 25 Sep 2002 17:33:30 -0400 (EDT) Message-ID: <3D922BAA.4000705@hp.com> Date: Wed, 25 Sep 2002 17:33:30 -0400 From: Vladislav Yasevich Organization: Hewlett Packard User-Agent: Mozilla/5.0 (X11; U; OSF1 alpha; en-US; rv:0.9.9) Gecko/20020318 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Hunter Cc: jinmei@isl.rdc.toshiba.co.jp, ipng@sunroof.eng.sun.com Subject: Re: 2292bis ip6_rthdr0 flexible array member References: <20020911152942.42f48e0d.michael.hunter@eng.sun.com> <20020923130121.4bdf9280.michael.hunter@eng.sun.com> <20020925135258.3861fa68.michael.hunter@eng.sun.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Let me see if I can remember the reasons I had for removing the array. 1. It would make the structure declaration similar to the rest of extension headers. 2. 2292 and early 2292bis defined the array of size 1, but it is valid to have a routing header with 0 segleft and no IPv6 addresses. This corner case caused a bunch of small problems for implementations that the new definition avoided. 3. Not all compilers understood flexible array member. It also caused some confusion from users expecting sizeof() to be different. Additionally 2292bis has some other incompatibilities with 2292 this one being the least of the problems. So that argument doesn't fly. -vlad Michael Hunter wrote: > On Wed, 25 Sep 2002 22:00:56 +0900 > JINMEI Tatuya / $B?@L@C#:H(B wrote: > [...] > >>I didn't remember the reason why the member name was removed, so I >>found it from the web. You'll get the answer from the discussion >>starting at the following URL: >> >>http://www.wcug.wwu.edu/lists/ipng/199908/msg00128.html >> >>According to the discussion, there seemed to be a clear consensus on >>the removal (though this may not be regarded as a "strong reason"). > > > poster + > 1 FAM preferred (removal next) > 1 removal > 1 its nice to have the array member > 1 but I don't need the array member > > I'm not sure what the overall membership of the interested parties was > but that doesn't sound like a large sample. > > [...] > >>Another thought: most user applications are expected to use >>inet6_rth_xxx functions, instead of directly getting access to the >>address part following the rthdr[0] structure. Thus, either 1 nor 2 >>affects the typical user applications. > > > So why create incompatibilities with 2292 if you expect the feature > being broken to be used less in the future? Whats the gain? > > [...] > >>Having thought all of this, I still prefer the current 2292bis >>definition. (I personally could live with (2), but I prefer (1) over >>(2) because we had a clear consensus on this.) >> >>Can we agree on this, or do we need more discussion? > > > I'm not buying the reasons I've seen so far for this incompatibility > with 2292. I believe you need a reason other then "its ugly" to break > users code. > > mph > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Tru64 UNIX - IPv6 Project Lead Hewlett Packard Tel: (603) 884-1079 Nashua, NH 03062 ZKO3-3/T07 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 25 20:52:21 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8Q3qLwf020122; Wed, 25 Sep 2002 20:52:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8Q3qL1f020121; Wed, 25 Sep 2002 20:52:21 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8Q3qFwf020114 for ; Wed, 25 Sep 2002 20:52:15 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8Q3qKMq008765 for ; Wed, 25 Sep 2002 20:52:21 -0700 (PDT) Received: from hclnpd.hclt.co.in ([202.54.64.7]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA05859 for ; Wed, 25 Sep 2002 21:52:14 -0600 (MDT) Received: from blaze.hcltech.com (blaze.hclt-ntl.co.in [192.168.19.30]) by hclnpd.hclt.co.in with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SP90T6ZY; Thu, 26 Sep 2002 09:22:18 +0530 Received: from rajesh.netlab.hcltech.com ([192.168.19.147]) by blaze.hcltech.com (8.9.3/8.9.3) with ESMTP id JAA19954 for ; Thu, 26 Sep 2002 09:51:17 +0530 Message-Id: <4.3.2.7.1.20020926090834.00da4ad0@blaze> X-Sender: nrajesh@blaze X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 26 Sep 2002 09:09:02 +0530 To: ipng@sunroof.eng.sun.com From: Rajesh N Subject: IPV6 linux kernel functions Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_88608081==_.ALT" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --=====================_88608081==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi group, I am fresh to both ipv6 and linux kernel programming..I am trying to learn networking stack implementation of Linux kernel 2.4.7...Could someone please clarify a few doubts... 1. I find a few structure definitions related to IPV6 headers in both (a)/usr/include/netinet/ip6.h and /usr/include/linux/ipv6.h . For example, IPV6 Routing extension header is defined as struct ip6_rthdr in (a) and struct ipv6_rt_hdr in (b). I think, similar duplication is there for many such protocol headers like icmp, tcp etc. Why do we have such duplication? 2. How are ipv6 headers getting getting filled, when a source sends a packet to a destination. Could someone direct me to an explanation of flow in the stack. Or even, a direction towards the functions to be explored to understand these concepts.. Thanks in advance Regards, Rajesh N --=====================_88608081==_.ALT Content-Type: text/html; charset="us-ascii" Hi group,

I am fresh to both ipv6 and linux kernel programming..I am trying to learn networking stack implementation of Linux kernel 2.4.7...Could someone please clarify a few doubts...

1. I find a few structure definitions related to IPV6 headers in both (a)/usr/include/netinet/ip6.h and /usr/include/linux/ipv6.h . For example, IPV6 Routing extension header is defined as struct ip6_rthdr in (a)
and struct ipv6_rt_hdr in (b). I think, similar duplication is there for many such protocol headers like icmp, tcp etc. Why do we have such duplication?

2. How are ipv6 headers getting getting filled, when a source sends a packet to a destination. Could someone direct me to an explanation of flow in the stack. Or even, a direction towards the functions to be explored to understand these concepts..

Thanks in advance

Regards,
Rajesh N --=====================_88608081==_.ALT-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 25 21:03:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8Q43Wwf020187; Wed, 25 Sep 2002 21:03:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8Q43Wji020186; Wed, 25 Sep 2002 21:03:32 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8Q43Owf020178 for ; Wed, 25 Sep 2002 21:03:24 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8Q43TMq011283; Wed, 25 Sep 2002 21:03:29 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA28423; Wed, 25 Sep 2002 21:03:23 -0700 (PDT) Received: from localhost ([3ffe:501:4819:2000:f8c1:9bf8:d4be:2d16]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g8Q43Lt00671; Thu, 26 Sep 2002 13:03:21 +0900 (JST) Date: Thu, 26 Sep 2002 13:03:53 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Michael Hunter Cc: ipng@sunroof.eng.sun.com Subject: Re: 2292bis ip6_rthdr0 flexible array member In-Reply-To: <20020925135258.3861fa68.michael.hunter@eng.sun.com> References: <20020911152942.42f48e0d.michael.hunter@eng.sun.com> <20020923130121.4bdf9280.michael.hunter@eng.sun.com> <20020925135258.3861fa68.michael.hunter@eng.sun.com> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 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 20000228(IM140) Lines: 89 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Wed, 25 Sep 2002 13:52:58 -0700, >>>>> Michael Hunter said: > [...] >> I didn't remember the reason why the member name was removed, so I >> found it from the web. You'll get the answer from the discussion >> starting at the following URL: >> >> http://www.wcug.wwu.edu/lists/ipng/199908/msg00128.html >> >> According to the discussion, there seemed to be a clear consensus on >> the removal (though this may not be regarded as a "strong reason"). > poster + > 1 FAM preferred (removal next) > 1 removal > 1 its nice to have the array member > 1 but I don't need the array member I could not tell who is who, so please let me be more concrete. Vlad proposed to remove the member. Francis agreed. Tim agreed. Erik first said the member was useful but then followed the suggestion anyway. (correct me if I'm wrong or miss someone.) > I'm not sure what the overall membership of the interested parties was > but that doesn't sound like a large sample. I'm not sure, either. But API discussions are often like this. > [...] >> Another thought: most user applications are expected to use >> inet6_rth_xxx functions, instead of directly getting access to the >> address part following the rthdr[0] structure. Thus, either 1 nor 2 >> affects the typical user applications. > So why create incompatibilities with 2292 if you expect the feature > being broken to be used less in the future? Whats the gain? See Vlad's response. >> Having thought all of this, I still prefer the current 2292bis >> definition. (I personally could live with (2), but I prefer (1) over >> (2) because we had a clear consensus on this.) >> >> Can we agree on this, or do we need more discussion? > I'm not buying the reasons I've seen so far for this incompatibility > with 2292. I believe you need a reason other then "its ugly" to break > users code. I think the fact that we can have a routing header without any address is a reasonable reason to remove ip6r0_addr[1] other than the style issue (I guess that's the main reason why Erik added this change in the 01 version of the draft). Additionally, I suspect the removal actually breaks user code so much. As I said before, user applications are usually expected to use library functions for source routing and to not use the ip6r0_addr member directly. In fact, we, the KAME project, do not use the member name in about 80 IPv6 applications we provide. I also searched on recent source code of FreeBSD and NetBSD (which have not supported 2292bis yet). The only occurrence of ip6r0_addr other than in user applications is in tcpdump, where no compatibility issue exists since tcpdump uses its own header definitions. Of course, I'm not saying the above is all of IPv6 applications, but it should definitely covers a noticeable part of them, particularly in the open source area where the compatibility issue is severer. As Vlad said, 2292bis has already broken compatibility to the old RFC2292 in many points (I admit this is a weird thing, but this is the fact and was decided by this community). And the examples above show that this is a relatively minor issue among them in the real world. Thus, I would prefer the new definition in 2292bis because of the reasons Vlad raised. I understand your frustration, but I'm afraid no one can "win" in this kind of discussion. We just need a compromise, and I hope you kindly allow us to go with the current definition. 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 Sep 25 21:57:45 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8Q4viwf020377; Wed, 25 Sep 2002 21:57:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8Q4viei020376; Wed, 25 Sep 2002 21:57:44 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8Q4vcwf020369 for ; Wed, 25 Sep 2002 21:57:38 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8Q4vgPG019886 for ; Wed, 25 Sep 2002 21:57:42 -0700 (PDT) Received: from ALPHA2.ITS.MONASH.EDU.AU (alpha2.its.monash.edu.au [130.194.1.4]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA05377 for ; Wed, 25 Sep 2002 21:57:36 -0700 (PDT) Received: from kapow.its.monash.edu.au ([130.194.1.71]) by vaxc.cc.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01KMYLCMR2ES9DPOC4@vaxc.cc.monash.edu.au> for ipng@sunroof.eng.sun.com; Thu, 26 Sep 2002 14:57:21 +1000 Received: from kapow.its.monash.edu.au (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 4BC6020036; Thu, 26 Sep 2002 14:57:20 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by kapow.its.monash.edu.au (Postfix) with ESMTP id 1FA2820014; Thu, 26 Sep 2002 14:57:20 +1000 (EST) Date: Thu, 26 Sep 2002 14:57:20 +1000 From: Greg Daley Subject: Re: IPV6 linux kernel functions To: Rajesh N Cc: ipng@sunroof.eng.sun.com Reply-to: greg.daley@eng.monash.edu.au Message-id: <3D9293B0.7010806@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 References: <4.3.2.7.1.20020926090834.00da4ad0@blaze> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello Rajesh some of the headers are defined directly from RFCs. in this case RFC 2292 is one of the RFC's used. If you refer to this document, you will see that linux uses some examples of these headers verbatim. Also, implementation specific queries should be directed to support services for that OS. This list is for standards discussion. In the Linux case, that's netdev@oss.sgi.com Greg Daley Rajesh N wrote: > Hi group, > > I am fresh to both ipv6 and linux kernel programming..I am trying to > learn networking stack implementation of Linux kernel 2.4.7...Could > someone please clarify a few doubts... > > 1. I find a few structure definitions related to IPV6 headers in both > *(a)*/usr/include/netinet/ip6.h and /usr/include/linux/ipv6.h . For > example, IPV6 Routing extension header is defined as struct ip6_rthdr in > *(a) > *and struct ipv6_rt_hdr in *(b)*. I think, similar duplication is there > for many such protocol headers like icmp, tcp etc. Why do we have such > duplication? > > 2. How are ipv6 headers getting getting filled, when a source sends a > packet to a destination. Could someone direct me to an explanation of > flow in the stack. Or even, a direction towards the functions to be > explored to understand these concepts.. > > Thanks in advance > > Regards, > Rajesh N -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 25 22:04:38 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8Q54cwf020435; Wed, 25 Sep 2002 22:04:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8Q54cVj020434; Wed, 25 Sep 2002 22:04:38 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8Q54Uwf020427 for ; Wed, 25 Sep 2002 22:04:30 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8Q54YPG021946; Wed, 25 Sep 2002 22:04:34 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA08084; Wed, 25 Sep 2002 22:04:28 -0700 (PDT) Received: from localhost ([3ffe:501:4819:2000:f8c1:9bf8:d4be:2d16]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g8Q54Pt01076; Thu, 26 Sep 2002 14:04:25 +0900 (JST) Date: Thu, 26 Sep 2002 14:04:57 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Michael Hunter Cc: ipng@sunroof.eng.sun.com Subject: Re: 2292bis ip6_rthdr0 flexible array member In-Reply-To: References: <20020911152942.42f48e0d.michael.hunter@eng.sun.com> <20020923130121.4bdf9280.michael.hunter@eng.sun.com> <20020925135258.3861fa68.michael.hunter@eng.sun.com> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 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 20000228(IM140) Lines: 20 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Thu, 26 Sep 2002 13:03:53 +0900, >>>>> JINMEI Tatuya said: > Additionally, I suspect the removal actually breaks user code so much. > As I said before, user applications are usually expected to use > library functions for source routing and to not use the ip6r0_addr > member directly. In fact, we, the KAME project, do not use the member > name in about 80 IPv6 applications we provide. I also searched on > recent source code of FreeBSD and NetBSD (which have not supported > 2292bis yet). The only occurrence of ip6r0_addr other than in user ^^^^^^^^^^"other than" should be removed. sorry for the confusing wording. > applications is in tcpdump, where no compatibility issue exists since > tcpdump uses its own header definitions. 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 Sep 26 01:21:21 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8Q8LLwf021626; Thu, 26 Sep 2002 01:21:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8Q8LL2C021625; Thu, 26 Sep 2002 01:21:21 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8Q8LGwf021618 for ; Thu, 26 Sep 2002 01:21:16 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8Q8LKMq026790 for ; Thu, 26 Sep 2002 01:21:20 -0700 (PDT) Received: from hclnpd.hclt.co.in ([202.54.64.7]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA02842 for ; Thu, 26 Sep 2002 01:21:14 -0700 (PDT) Received: from blaze.hcltech.com (blaze.hclt-ntl.co.in [192.168.19.30]) by hclnpd.hclt.co.in with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SP90T960; Thu, 26 Sep 2002 13:51:17 +0530 Received: from rajesh.netlab.hcltech.com ([192.168.19.147]) by blaze.hcltech.com (8.9.3/8.9.3) with ESMTP id OAA24324 for ; Thu, 26 Sep 2002 14:20:16 +0530 Message-Id: <4.3.2.7.1.20020926132525.00db1c20@blaze> X-Sender: nrajesh@blaze X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 26 Sep 2002 13:38:02 +0530 To: ipng@sunroof.eng.sun.com From: Rajesh N Subject: How PING6 works Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi group, I am a bit confused about how ping6 works in an ethernet... Assume I have a simple ethernet lan, with few private subnets, say 192.168.10.0 and 192.168.20.0, connected by a local gateway (G) with interfaces 192.168.10.5 and 192.168.20.5. Now, I have a PC each on these subnets, say with IPV4 addresses (A)192.168.10.15 and (B)192.168.20.15 configured with IPV6 linux, so that each of them have a link local IPV6 addresses starting with fe80: Now when I do a ping6 from A like, 'ping6 -I eth0 link-local-IPV6address-of-B' I get a reply. How does this work? My understanding is that the ICMPV6 datagram containing the echo request of ping program is put in an IPV6 datagram, which is put in an ethernet frame and send down to G. But for G's routing module to understand the destination IPV6 address of B, should there be any special protocol running on it? Sorry if my queston is confusing...Pls direct me to a good explanation of how IPV6 works in an ethernet.. Thanks in advance Regards, Rajesh N -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 26 02:14:04 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8Q9E4wf021957; Thu, 26 Sep 2002 02:14:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8Q9E4ro021956; Thu, 26 Sep 2002 02:14:04 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8Q9Dwwf021949 for ; Thu, 26 Sep 2002 02:13:58 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8Q9E3Mq010827 for ; Thu, 26 Sep 2002 02:14:03 -0700 (PDT) Received: from ratree.psu.ac.th ([202.12.73.3]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA27068 for ; Thu, 26 Sep 2002 02:12:00 -0700 (PDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g8Q9A7J14289; Thu, 26 Sep 2002 16:10:07 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g8Q9A1713222; Thu, 26 Sep 2002 16:10:02 +0700 (ICT) From: Robert Elz To: Rajesh N cc: ipng@sunroof.eng.sun.com Subject: Re: How PING6 works In-Reply-To: <4.3.2.7.1.20020926132525.00db1c20@blaze> References: <4.3.2.7.1.20020926132525.00db1c20@blaze> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 26 Sep 2002 16:10:01 +0700 Message-ID: <13220.1033031401@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 26 Sep 2002 13:38:02 +0530 From: Rajesh N Message-ID: <4.3.2.7.1.20020926132525.00db1c20@blaze> | Now when I do a ping6 from A like, 'ping6 -I eth0 | link-local-IPV6address-of-B' I get a reply. How does this work? If you know how this works if it were IPv4 instead of IPv6, then you also know how it works (in essence) for IPv6, there are no differences of significance (only details). If you don't know how it works for IPv4, there are lots of good text books available (and some not so good, but never mind) that will explain it all. 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 Sep 26 05:03:24 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QC3Nwf022731; Thu, 26 Sep 2002 05:03:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8QC3NBk022730; Thu, 26 Sep 2002 05:03:23 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8QC3Iwf022723 for ; Thu, 26 Sep 2002 05:03:18 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8QC3LMq024278 for ; Thu, 26 Sep 2002 05:03:21 -0700 (PDT) Received: from ncsmtp03.ogw.rr.com (ncsmtp03.ogw.rr.com [24.93.67.84]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA10679 for ; Thu, 26 Sep 2002 05:03:15 -0700 (PDT) Received: from mail5.nc.rr.com (fe5 [24.93.67.52]) by ncsmtp03.ogw.rr.com (8.12.5/8.12.2) with ESMTP id g8QC39iZ012353; Thu, 26 Sep 2002 08:03:09 -0400 (EDT) Received: from nc.rr.com ([63.109.132.2]) by mail5.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Thu, 26 Sep 2002 08:03:14 -0400 Message-ID: <3D92E961.70108@nc.rr.com> Date: Thu, 26 Sep 2002 07:02:57 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: magma@ietf.org, ipng@sunroof.eng.sun.com Subject: MAGMA WG Last Call: draft-ietf-magma-mld-source-01.txt Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk All, This starts the MAGMA Working Group 2 week Last Call period for draft-ietf-magma-mld-source-01.txt. The Last Call will end on October 3rd. Substantive comments should be directed to the MAGMA mailing list. Editorial comments can be made to the author. Regards, Brian & Bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Sep 26 23:29:02 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8R6T2bj006318; Thu, 26 Sep 2002 23:29:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8R6T2dp006317; Thu, 26 Sep 2002 23:29:02 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8R6Sxbj006310 for ; Thu, 26 Sep 2002 23:28:59 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8R6T3PG026546 for ; Thu, 26 Sep 2002 23:29:04 -0700 (PDT) Received: from basit.cc (wireless.cs.twsu.edu [156.26.10.125]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA08862 for ; Fri, 27 Sep 2002 00:28:57 -0600 (MDT) Received: from [127.0.0.1] (helo=localhost) by basit.cc with esmtp (Exim 4.10) id 17uoGs-0000wo-00 for ipng@sunroof.eng.sun.com; Fri, 27 Sep 2002 01:06:38 -0500 Date: Fri, 27 Sep 2002 01:06:38 -0500 (CDT) From: Abdul Basit X-X-Sender: basit@wireless.cs.twsu.edu To: ipng@sunroof.eng.sun.com Subject: LIN6 & MIPv6 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, I was just reading the LIN6 (Location independent networking) draft ( http://www.lin6.net/draft/draft-teraoka-ipng-lin6-01.txt), I wonder if LIN6 solves every problem of MIPv6 , then what are its limitations , i thought of like in LIN6 , if a mobile node's DNS name resolves in two LIN6 generalized address then what it will pick ? I am just curious if in future work will be proceed with LIN6 or MIPv6 ? - basit -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 28 00:55:39 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8S7tdbj014270; Sat, 28 Sep 2002 00:55:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8S7tdW5014269; Sat, 28 Sep 2002 00:55:39 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8S7tZbj014261 for ; Sat, 28 Sep 2002 00:55:36 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8S7tdPG019884 for ; Sat, 28 Sep 2002 00:55:39 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA27379 for ; Sat, 28 Sep 2002 00:55:33 -0700 (PDT) Received: from lucernhammer.isl.rdc.toshiba.co.jp ([3ffe:501:100f:1048:203:93ff:fe84:85c8]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g8S7sSt19686; Sat, 28 Sep 2002 16:54:29 +0900 (JST) Date: Sat, 28 Sep 2002 16:54:33 +0900 Message-ID: From: Masahiro =Rhythm Drive= Ishiyama To: Abdul Basit Cc: ipng@sunroof.eng.sun.com Subject: Re: LIN6 & MIPv6 In-Reply-To: References: User-Agent: Wanderlust/2.6.1 (Upside Down) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (Unebigoryomae) APEL/10.3 Emacs/20.7 (powerpc-apple-darwin6.0) MULE/4.0 (HANANOEN) Organization: Toshiba Corp. R&D Center. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 15 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Fri, 27 Sep 2002 01:06:38 -0500 (CDT), Abdul Basit said: > I was just reading the LIN6 (Location independent networking) > draft ( http://www.lin6.net/draft/draft-teraoka-ipng-lin6-01.txt), > I wonder if LIN6 solves every problem of MIPv6 , then what > are its limitations , i thought of like in LIN6 , if a mobile node's > DNS name resolves in two LIN6 generalized address then what it will pick ? Well, it depends on a resolver the node uses. Such configuration, assigning multiple different LIN6 generalized IDs to one FQDN, is usually intended for load-balancing, so I think it is not so important issue which one will be picked. masahiro -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 28 04:36:27 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8SBaQbj014946; Sat, 28 Sep 2002 04:36:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8SBaQix014945; Sat, 28 Sep 2002 04:36:26 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8SBaNbj014938 for ; Sat, 28 Sep 2002 04:36:23 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8SBaRMq027682 for ; Sat, 28 Sep 2002 04:36:27 -0700 (PDT) Received: from vmmr1.verisignmail.com (vmmr1.verisignmail.com [216.168.230.137]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA11212 for ; Sat, 28 Sep 2002 05:36:22 -0600 (MDT) Received: from vmms1.verisignmail.com (vmms1.verisignmail.com [10.166.0.138]) by vmmr1.verisignmail.com (Mirapoint Messaging Server MOS 2.9.3.2) with ESMTP id PGG00301; Sat, 28 Sep 2002 07:36:18 -0400 (EDT) Received: from forever (pool-141-153-228-34.mad.east.verizon.net [141.153.228.34]) by vmms1.verisignmail.com (Mirapoint Messaging Server MOS 2.9.3.2) with SMTP id PXQ00221; Sat, 28 Sep 2002 07:36:16 -0400 (EDT) Reply-To: From: "Nigel Clarke" To: Subject: IPv4/IPv6 comparison Date: Sat, 28 Sep 2002 07:36:06 -0700 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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I have to write a paper on IPv6. What this requires is that I compare IPv6 to v4 and indicates the protocol differences and enhancements. I've already tried Google, and I've come up with nothing. I was hoping that there might be some information available through the mailing list. Thanks, Nigel -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 29 21:16:37 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8U4Gbbj024925; Sun, 29 Sep 2002 21:16:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8U4Ga1Z024924; Sun, 29 Sep 2002 21:16:36 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8U4GXbj024917 for ; Sun, 29 Sep 2002 21:16:33 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8U4GYMq000564 for ; Sun, 29 Sep 2002 21:16:34 -0700 (PDT) Received: from basit.cc (wireless.cs.twsu.edu [156.26.10.125]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA08190 for ; Sun, 29 Sep 2002 22:16:28 -0600 (MDT) Received: from [127.0.0.1] (helo=localhost) by basit.cc with esmtp (Exim 4.10) id 17vrmC-0003Sm-00; Sun, 29 Sep 2002 23:03:20 -0500 Date: Sun, 29 Sep 2002 23:03:20 -0500 (CDT) From: Abdul Basit X-X-Sender: basit@wireless.cs.twsu.edu To: ipng@sunroof.eng.sun.com cc: usagi-users@linux-ipv6.org Subject: proxy ARP/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 Hi, I was trying to setup up a proxy arp kind of thing for IPv6 host here is the scenario interface: eth0 interface: tap0 ------------ via TUN/TAP ------------- |ipv6-1 | <-----------> | | ------> [[[[ internet6]]]]] | | | maryo | |---------- |___________| ipv6-1 runs runs usagi 16sept02 vanilla linux 2.4.19 maryo can ping6 outside ipv6 hosts perfectly. maryo has following interface(s): eth0, tap0,ngc-maryo ... nag-maryo(tunnel mode sit) : assigned 3ffe:8271:a026:feee::1 assigned 3ffe:8271:a026:feee::/64 route. eth0(ethernet) : assigned 3ffe:8271:a026:feee::2 tap0(TUN/TAP) : assigned 3ffe:8271:a026:feee::3 assigned a route of host 3ffe:8271:a026:feee::4 (all these ip addresses can be directly reached by outside perfectly). Now the ipv6-1 host has following interfaces eth0 (TUN/TAP actually to tap0) : assigned 3ffe:8271:a026:feee::4 assigned route 3ffe:8271:a026:feee::/64 Now from the host ipv6-1 i can ping6 3ffe:8271:a026:feee::3 fine but NOT 3ffe:8271:a026:feee::1 ? i assume , i need to setup some sort of relay for neighhour discovery messages for 3ffe:8271:a026:feee i tried ip -6 neigh add proxy 3ffe:8271:a026:feee::4 dev ngc-maryo / eth0 both, but don't seems to work. Please help. Thanks - basit -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 29 21:23:20 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8U4NKbj024987; Sun, 29 Sep 2002 21:23:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8U4NKtx024986; Sun, 29 Sep 2002 21:23:20 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8U4NGbj024979 for ; Sun, 29 Sep 2002 21:23:17 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8U4NMMq001324 for ; Sun, 29 Sep 2002 21:23:23 -0700 (PDT) Received: from basit.cc (wireless.cs.twsu.edu [156.26.10.125]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA11145 for ; Sun, 29 Sep 2002 22:23:16 -0600 (MDT) Received: from [127.0.0.1] (helo=localhost) by basit.cc with esmtp (Exim 4.10) id 17vrpk-0003Sw-00; Sun, 29 Sep 2002 23:07:00 -0500 Date: Sun, 29 Sep 2002 23:07:00 -0500 (CDT) From: Abdul Basit X-X-Sender: basit@wireless.cs.twsu.edu To: ipng@sunroof.eng.sun.com cc: usagi-users@linux-ipv6.org Subject: proxy ARP/IPv6 (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk snaps of route are maryo:/proc/sys/net/ipv6# ip -6 route 3ffe:8271:a026:feee::4 dev tap0 metric 1024 mtu 1500 advmss 1440 3ffe:8271:a026:feee::/64 dev ngc-maryo metric 1024 mtu 1480 advmss 1420 fe80::/64 dev eth0 proto kernel metric 256 mtu 1500 advmss 1440 fe80::/64 dev eth1 proto kernel metric 256 mtu 1500 advmss 1440 fe80::/64 dev tap0 proto kernel metric 256 mtu 1500 advmss 1440 fe80::/64 via :: dev ngc-maryo proto kernel metric 256 mtu 1480 advmss 1420 ff00::/8 dev eth0 proto kernel metric 256 mtu 1500 advmss 1440 ff00::/8 dev eth1 proto kernel metric 256 mtu 1500 advmss 1440 ff00::/8 dev tap0 proto kernel metric 256 mtu 1500 advmss 1440 ff00::/8 dev ngc-maryo proto kernel metric 256 mtu 1480 advmss 1420 default dev ngc-maryo metric 1024 mtu 1480 advmss 1420 ipv6-1:/# ip -6 route 3ffe:8271:a026:feee::/64 dev eth0 metric 1024 mtu 1500 advmss 1440 fe80::/10 dev eth0 proto kernel metric 256 mtu 1500 advmss 1440 ff00::/8 dev eth0 proto kernel metric 256 mtu 1500 advmss 1440 default dev eth0 proto kernel metric 256 mtu 1500 advmss 1440 unreachable default dev lo metric -1 error -101 if i ping6 from ipv6 ipv6-1:/# ping6 3ffe:8271:a026:feee::1 PING 3ffe:8271:a026:feee::1(3ffe:8271:a026:feee::1) from 3ffe:8271:a026:feee::4 : 56 data bytes >From ::1 icmp_seq=1 Destination unreachable: Address unreachable >From ::1 icmp_seq=2 Destination unreachable: Address unreachable >From ::1 icmp_seq=3 Destination unreachable: Address unreachable but ipv6-1:/# ping6 3ffe:8271:a026:feee::3 PING 3ffe:8271:a026:feee::3(3ffe:8271:a026:feee::3) from 3ffe:8271:a026:feee::4 : 56 data bytes 64 bytes from 3ffe:8271:a026:feee::3: icmp_seq=1 ttl=64 time=1.43 ms --- 3ffe:8271:a026:feee::3 ping statistics --- 1 packets transmitted, 1 received, 0% loss, time 0ms rtt min/avg/max/mdev = 1.437/1.437/1.437/0.000 ms Thanks - basit ---------- Forwarded message ---------- Date: Sun, 29 Sep 2002 23:03:20 -0500 (CDT) From: Abdul Basit To: ipng@sunroof.eng.sun.com Cc: usagi-users@linux-ipv6.org Subject: proxy ARP/IPv6 Hi, I was trying to setup up a proxy arp kind of thing for IPv6 host here is the scenario interface: eth0 interface: tap0 ------------ via TUN/TAP ------------- |ipv6-1 | <-----------> | | ------> [[[[ internet6]]]]] | | | maryo | |---------- |___________| ipv6-1 runs runs usagi 16sept02 vanilla linux 2.4.19 maryo can ping6 outside ipv6 hosts perfectly. maryo has following interface(s): eth0, tap0,ngc-maryo ... nag-maryo(tunnel mode sit) : assigned 3ffe:8271:a026:feee::1 assigned 3ffe:8271:a026:feee::/64 route. eth0(ethernet) : assigned 3ffe:8271:a026:feee::2 tap0(TUN/TAP) : assigned 3ffe:8271:a026:feee::3 assigned a route of host 3ffe:8271:a026:feee::4 (all these ip addresses can be directly reached by outside perfectly). Now the ipv6-1 host has following interfaces eth0 (TUN/TAP actually to tap0) : assigned 3ffe:8271:a026:feee::4 assigned route 3ffe:8271:a026:feee::/64 Now from the host ipv6-1 i can ping6 3ffe:8271:a026:feee::3 fine but NOT 3ffe:8271:a026:feee::1 ? i assume , i need to setup some sort of relay for neighhour discovery messages for 3ffe:8271:a026:feee i tried ip -6 neigh add proxy 3ffe:8271:a026:feee::4 dev ngc-maryo / eth0 both, but don't seems to work. Please help. Thanks - basit -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 30 04:46:46 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8UBkkbj025903; Mon, 30 Sep 2002 04:46:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8UBkkpp025902; Mon, 30 Sep 2002 04:46:46 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8UBkgbj025895 for ; Mon, 30 Sep 2002 04:46:42 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8UBkjPG005757 for ; Mon, 30 Sep 2002 04:46:46 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA03790 for ; Mon, 30 Sep 2002 05:46:39 -0600 (MDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29281; Mon, 30 Sep 2002 07:44:42 -0400 (EDT) Message-Id: <200209301144.HAA29281@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ipng@sunroof.eng.sun.com, zeroconf@merit.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-noisette-v6ops-unmannet-isp-reqts-00.txt Date: Mon, 30 Sep 2002 07:44:42 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : ISP requirements for IPv6 unmanaged networks Author(s) : Y. Noisette Filename : draft-noisette-v6ops-unmannet-isp-reqts-00.txt Pages : 0 Date : 2002-9-27 This document proposes to identify the elementary network functions required to automatically deploy an IPv6 home network, i.e. with the minimum (and ideally not a single) intervention from any administrator or any user. The next generation Internet Protocol, IPv6, is expected to being deployed in environments such as homes and SOHOs. However, most of the people making use of the Internet at home don't have enough knowledge to set up on their own the network and services. Therefore, this document exposes the requirements necessary to ease such a deployment, from an ISP point of view. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-noisette-v6ops-unmannet-isp-reqts-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-noisette-v6ops-unmannet-isp-reqts-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-noisette-v6ops-unmannet-isp-reqts-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" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-9-27131721.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-noisette-v6ops-unmannet-isp-reqts-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-noisette-v6ops-unmannet-isp-reqts-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-9-27131721.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 Sep 30 23:02:53 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g9162qbj029918; Mon, 30 Sep 2002 23:02:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g9162q9T029917; Mon, 30 Sep 2002 23:02:52 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g9162nbj029910 for ; Mon, 30 Sep 2002 23:02:49 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g9162sMq015294 for ; Mon, 30 Sep 2002 23:02:54 -0700 (PDT) Received: from alumnux.com ([203.197.124.190]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA03598 for ; Mon, 30 Sep 2002 23:02:47 -0700 (PDT) Received: from alumnux.com (hardy.alumnus.co.in [192.168.10.53]) by alumnux.com (8.9.3/8.9.3) with ESMTP id RAA16164 for ; Tue, 1 Oct 2002 17:08:46 +0530 Message-ID: <3D993A84.AC3F91EE@alumnux.com> Date: Tue, 01 Oct 2002 11:32:45 +0530 From: Partha Kumar Pal X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.7-10 i686) X-Accept-Language: en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: qurries on MBGP Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear Sir, Would anybody help me regarding some querries on BGP4+. My question are 1) In BGP4+ (MBGP), the Update may packet contain IPv6 address(s) as next hop (in the MP_REACH_NLRI attribute) along with the IPv4 address as the nexthop (in original BGP4 update packet). Now in this scenario, when an Update packet comes to an Router which purely implements IPv6 environment or IPv4 environment, how does it process the Update packet ? Does it ignore the IPv6 (IPv4)next hop in case when it purely implements IPv4(IPv6) environment? I am confuse here. Would you please clarify the thing? 2) This question is same as above but regarding NLRI field. 3) What exacly SNPA means? 4) How aggregation of routes in MBGP takes place? Does it same as what used to be in BGP4? If it is true, then what happened to the IPv4 address of the aggregator contained in the AGGRAGETOR attribute? 5) Does it necessasry to have the Dual stack for implementing MBGP? Thanks Regards. Partha Pal -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com --------------------------------------------------------------------